>>I have an app that updates some VFP tables separately from a main app that the users normally use. It runs all day on a Win2K3 server. It opens all the files shared, as does the main app. It will run fine for awhile, but then will start failing on the TABLEUPDATE command (all tables I'm updating are opened with table buffering). I have used AERROR after the table update to see what the issue is and what it gives me is an error 1099 Procedure Canceled. Not real helpful. There is no 1099 error listed in the VFP help. It seems that 1099 is associated with the VFP OLE driver. I'm accessing these tables directly via VFP, so I don't see how that would come into play. I'm wondering if it could be something in the RI code and have considered changing to the data-driven code that comes from the MegaFox book (or wherever it was - can't remember which book it was right now). I think Doug Hennig has some, too. Previously, I was having a different issue, but seem to have gotten around that. One of the tables would not open, giving me an error 108 File is in use by another user. Again, all the tables are opened in shared mode, so I was unclear why that was happening. I was unable to determine what was causing that, but since I was opening the tables as needed and closing them after use, I decided to leave the two tables that were causing this issue open all the time. That seems to have fixed that problem, but now I'm getting the failed updates with the 1099 error. Does anyone have any suggestions about how I might address this?
>>
>>Thanks,
>>
>>Russell Campbell
>
>Procedure cancelled can come from a trigger (RI, you're correct). We had these errors. You may want to dive deeper into the trigger's code.

Well, the 1099 error was caused by some test code I left in there. Doh! So now what I'm getting is a 109 error (Record is in use by another user). Well, this is a record that was added by the program and not one that any other user should be accessing. The table in question is an inventory transaction table, so there's never any editing of a record. It's all about adding records when it comes to that table, because it's just a record representing the removal (in this case) of a certain number of items from the inventory (which is represented in another table). So the inventory record has the qty available reduced by X and a record is placed into the inventory transaction table representing the fact that so-and-so user decremented the inventory for the item by X. The update fails on the inventory transaction table with the 109 error. Since any user performing an action that decrements inventory will create their own unique inventory transaction table record related to that decrement, no user should ever be interfering with another user's record. Possibly the record pointer in the inventory transaction table might be sitting on that record, but it would not be locked. Any thoughts on what might be causing this?