>>>>>>Michel- did you ever get closer to tracking down the cause/solution of this problem? If you remember, I had told you that in a couple of months of operation, I had seen the error twice. Well It is now more like twice daily. Two things have changed- 1. more users, and 2. Network problems. We are currently tracking doen the problems NLMs that are causing the network to bog, but it could take awhile. My errorhandler returns the line containing APPEND BLANK as the offender, so I assume that the real offender is in my stored procedure newid(). Here is the code in the DBC:
>>>>>>
>>>>>>FUNCTION NewID(tcAlias)
>>>>>>LOCAL lcAlias, ;
>>>>>> lnID, ;
>>>>>> lcOldReprocess, ;
>>>>>> lnOldArea
>>>>>>lnOldArea = SELECT()
>>>>>>IF PARAMETERS() < 1
>>>>>> lcAlias = UPPER(ALIAS())
>>>>>>ELSE
>>>>>> lcAlias = UPPER(tcAlias)
>>>>>>ENDIF
>>>>>>lcOldReprocess = SET('REPROCESS')
>>>>>>SET REPROCESS TO AUTOMATIC
>>>>>>IF !USED("idnums")
>>>>>> USE temptest!idnums IN 0
>>>>>>ENDIF
>>>>>>SELECT idnums
>>>>>>IF SEEK(lcAlias, "idnums", "table")
>>>>>> IF RLOCK()
>>>>>> lnID = idnums.nextid
>>>>>> REPLACE idnums.nextid WITH idnums.nextid + 1
>>>>>> REPLACE updated with datetime()
>>>>>> UNLOCK
>>>>>> ENDIF
>>>>>>ELSE && Table name was not found in idnums table. Create a new record and initialize it to 1
>>>>>> APPEND BLANK
>>>>>> REPLACE table WITH lcalias
>>>>>> REPLACE nextid WITH 1
>>>>>> REPLACE updated with datetime()
>>>>>> lnID = idnums.nextid
>>>>>>ENDIF
>>>>>>SELECT (lnOldArea)
>>>>>>SET REPROCESS TO lcOldReprocess
>>>>>>RETURN lnID
>>>>>>ENDFUNC
>>>>>>
>>>>>>If anyone can give me any insight as to why this is happening or how I can prevent it, I would be really appreciative. Every time this particular routine crashes, I have to do a bunch of record maintenance. This is costing me more time than I would like to spend on it.
>>>>>
>>>>>Eric,
>>>>> Instead of append blank, why not use an Insert?? This way you only have to have the header of the table you are adding data to for one shot, as apposed to the append blank, then replace ... series..
>>>>>
>>>>>Thanx!
>>>>>
>>>>>Tony Miller
>>>>>Vancouver, Wa
>>>>Ditto to the above! If two people add a new record at the same time the system can possibly see two blank records which will set off the ref int trigger. By using the "INSERT INTO ..." you will avoid that.
>>>>HTH //:^)
>>>I also see another danger...You need to use something like DO WHILE NOT RLOCK()
>>>instead of IF RLOCK(). If the record is locked by another then the number wont get incremented at at, it will simply bypass that section and go on about its merry way. This, in fact, may be the source of your problem!
>>>Let me know if you agree //:^)
>>My sggestion would be something like
>>
>>STORE .F. TO IS_ABORT
>>DO WHILE NOT RLOCK() AND NOT IS_ABORT
>> WAIT WINDOW 'Waiting for record' TIMEOUT 1
>> IF LASTKEY()=27
>> STORE .T. TO IS_ABORT
>> EXIT
>> ENDIF
>>ENDDO
>>
>>IF NOT IS_ABORT
>> lnID = idnums.nextid
>> REPLACE idnums.nextid WITH idnums.nextid + 1, updated with datetime()
>> UNLOCK
>>ENDIF

Larry- thanks for the reply. I don't believe that the section would be skipped over unless the user pressed escape. Issuing RLOCK() attempts to lock the record, and if it is in use by another user, waits until it can lock it, or until the user hits escape. (IN the case of SET REPROCESS TO AUTOMATIC). None of my users have reported seeing the "Attempting to lock ... Press Escape to Cancel" message at all.
I have changed my code, however, to use "Insert into" instead of "append blank". I hope that this will make a difference, but I somehow doubt it, because the only record that needs to be accessed by more than one user at time is the idnums record. Thanks for your help.