Tricking the Exception 3197 
Author Message
 Tricking the Exception 3197

Hi, could anyone suggest a better solution than the tweak below?

The problem:
exception # 3197 is raised sometimes when the record is NOT changed,
merely the page was locked.
This is the set up:
- DAO 3.5, VC++ 5
- pessimistic locking
- Fields: Auto (4B), Long, Text (5 chars), Text (50 chars)

1. Two MFC applications (App1, App2) accessing one table
2. App1: accesses rec1, App2 adds rec2; rec1 != rec2
3. App1: Update on rec1 OK
4. App2: AddNew method OK, no exceptions raised (rec2)
5. App2: Update method raises (sometimes) exception 3197

App1 could have had a page locked but then I'd expect
that App2's Update would raise "locked" exception, e.g. 3260 or like.

I need to distinguish in Update method between the above case (automatically
retry Update) and the case the data really were changed (let the user handle

Q: How do I identify it?

Currently, I look at CDaoException -> m_pErrorInfo -> m_lErrorCode (for
and CDaoException - > m_pErrorInfo -> m_lHelpContext (for 5003197)

if both values match then return to user (record was really changed)
if HelpContext is different (say 5003186, 5003260) then try Update again

It does not sound as a good practice - how else should I handle it?



Fri, 07 Mar 2003 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Tricking the Exception 3197

2. !!! ODBC/DAO/Error 3197/Write Conflict/ANSI_NULL/TimeStamp !!!

3. Error 3197:

4. DAO err 3197 Instead of "Data Locked"

5. Tricking IsPostBack?

6. Translate a SEH exception into a C++ exception

7. IDE Tricks (was Re: c# Coding Convention)

8. eschew obfuscation (was Neat C trick again)

9. eschew obfuscation (was Neat C trick again)

10. Soap Exception -- Inner Exception

11. Old Dog / New Tricks: Strings vs. Structures

12. Compiler trick wanted


Powered by phpBB® Forum Software