>Bret,
>
>Sorry, if this is unrelevant. Could it be, that your GetKey procedure produces NULL in case of error (say, record could not be locked). I do it intentionally in my GetKey procedure.
>


You hit the nail right on the head. The GetKey was producing an error due to 2 things. One the Set Exact and another I changed a piece of code in the GetKey from SEEK (tcTableName) to SEEK UPPER(tcTableName). I must have looked at the code a thousand times Friday and never saw it. The call was never generating an error, but just returning a NULL. Today I come in and look over the code again and see the SEEK error right off.

Isn't it great how a weekend can aid in overcoming stupidity brought on by exhaustion. Thanks for your reply Nadya and Mark thanks for your time also even though now I think I wasted it.


>>>You are correct in that a field identified as a PRIMARY KEY field will never allow null values. I understand what the error is, but I do not know why it is failing since the default value of the field appears to be correct. Did you check the table used to retrieve the PK ID from to see if it is populated with an actual value instead of a null value? There are only 3 possibilities that I know of that could fail this process. The first is the default value defined for the field, the second is that a valid value exists in your Kounters table where the next ID is retrieved from. The third is the GetKey() stored procedure actually exists in the active database. There is only 1 database that is open when this insert fires, right? I have had this problem, but it was because the default value for the PK field got wiped out. Is the GetKey SP looking for the correct table name [probably so] and is the lookup of the table in the Kounters table case sensitive [should not be]. If all is firing
>>>correctly, the value in the UsrKey field will NEVER be null, even for a split second. VFP should be seeing the the default value is GETKEY('user') and populate that value with the return value from the SP before actually executing the INSERT command.
>>>
>>>Try to simulate this on your dev machine. Create a connection handle to your DBC using the FoxPro ODBC driver. Then do an INSERT with SQLExec and see if you get the same error.
>>>
>>
>>Will do Mark and thanks for your time. I will post my results or a solution if found here. I just love these days where you think you have been making great progress only to have your day slowed down to a crawl with Debugging and Testing and Unknowns. But hey that is the life I chose, at least until I can make it to retirement.