I'm seeking help on a problem. I have a system that has been in place many years and we are just now having a problem crop up on the tableupdate using optimistic table buffering. This is an order entry system and it's the order detail lines that I'm having trouble with. In the past it's only been a couple of records. With the latest use of this app they are entering in about 10 records at a time. I'm even doing a loop with multiple retries on the tableupdate, and I've since changed this table to use pessimistic table buffering without success. The aerror is return record is in use by another when 2 different orders are entered. I don't have a primary key index, I can't see any reason for this conflic. I've just never run into this before and I've written a lot of systems using the same code, any recommendations would be appreciated.
Thanks in advance.
First, a question: are you using views? If so, what is your update method? The fact that you say you don't have a primary key index throws up a lot of red flags. You should ALWAYS have a primary key, even if it's on a detail set of records. Using views, especially, but a good practice nonetheless. Try adding a primary key to this table and if using a view, make sure the update method is set to "key and modified". Hope this helps. -- Randy Jean
Did you recently upgrade from a prior version of VFP, like 7 or earlier.
If so then *possibly* SET TABLEVALIDATE may be at play here. You might try setting it to 0 temporarily, but longer term to the value that only attempts locking at write time.
Good luck. -- Jim Nelson
I did upgrade, but this was one of the reasons for the upgrade so this was happening in 6.0. I will change teh set tablevalidate anyway to take that out of the mix.
Regarding the PK, I do have a PK field, what I was trying to say was I did not make the index for the PK field a primary type of index because I've had problems with doing this in the past, I am not using views.
And I think I have an answer to this. Even though aerror was giving me record in use it looks like it was the trigger it was having a problem with. Taking this out in inital testing seems to be successful. Basically the trigger was for an audit trail, apparently too much action on this stored procedure doesn't work. A couple of records okay, 10 records, not okay. I wouldn't mind any feedback regarding this as I really like being able to just have one audittrail procedure as a stored procedure instead of keeping this information in the individual tables. --Stacie
Category Key Fields
( Topic last updated: 2005.08.31 03:24:03 PM )