>I propose that you guys are doing something suspicious in these stored procedures. I use this technique all of the time in many different apps, and have never had that problem.
>
>Would you be game for posting the procedure at fault?

This is the code I had in the DBC the last time I had problems. It's a procedure for getting a new primary key. It's an old bit of code I got from someone down the line that was probably written for FP 2.6. It works in VFP, but I suppose it wouldn't be a bad idea to update it.

PROCEDURE Next_ID &&Next_ID('table name')
lparameters lcTABLE
local lnCURR_SEL, llUSED, lnCURR_REPR, lnKEY

* Save the current work area, open the NEXTID table (if necessary), and find
* the desired table. If it doesn't exist, create a record for it.

lnCURR_SEL = SELECT()
llUSED = USED('NEXTID')
IF llUSED
SELECT NEXTID
SET ORDER TO TABLE
ELSE
SELECT 0
USE NEXTID ORDER TABLE
ENDIF llUSED
SEEK UPPER(lcTABLE)
IF NOT FOUND()
INSERT INTO NEXTID VALUES (lcTABLE, 0)
ENDIF not found()

* Increment the next available ID.

lnCURR_REPR = SET('REPROCESS')
SET REPROCESS TO 10 SECONDS
IF RLOCK()
REPLACE ID WITH ID + 1
lnKEY = ID
UNLOCK
ELSE
lnKEY = 0 && Force it to a numeric type before setting it to .NULL.
lnKEY = .NULL.
ENDIF rlock()

* Cleanup and return.

SET REPROCESS TO lnCURR_REPR
IF NOT llUSED
USE
ENDIF not llUSED
SELECT (lnCURR_SEL)
RETURN lnKEY

ENDPROC