Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
File in use by another Error Message
Message
From
24/05/1999 18:58:20
 
 
To
24/05/1999 18:29:24
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00222087
Message ID:
00222263
Views:
19
Hi, Bonnie-

Thanks for the explanation.

>OK, here's what I'm doing, and as I said, I know I'm handling this wrong, but it shouldn't matter as far as this error goes (but who knows, maybe it does?)

I hope you don't take this the wrong way, but it might be simpler to straighten out the transactions and buffering. The problem may be due to the incorrect use of the two techniques. IOW, it's not that it's wrong as is IMHO the ultimate cause of the conflict.

>As soon as the user starts editting (by typing in the field), I issue a BEGIN TRANSACTION.

Just for jollies, what happens if you just comment this code out?

Buffering is the technique to use to accomplish what it seems like you are going for using transactions. Combining the two in the way you are seems destined for trouble. It's not that I don't want to help you get it running...it's that even if you can kludge it so the error doesn't occur, I think you'll see all kinds of real showstoppers when the app is in multi-user.

For example, the BEGIN TRANSACTION is going to lock each file as you table update. If a user goes to lunch during an edit, everybody will be trashed. :-(

>IF they save, then I do a TABLEUPDATE and an END TRANSACTION (redundant?). If they cancel, I do a ROLLBACK.
If you looked at my example in my previous post, you'll notice I do both. They aren't redundant because buffering and transactions are two different things. Similar in that they are techniques that allow us to control when and how data is written to the original tables, but still different.

Buffering just means that your edits take place on a copy of the data in memory. You use tableupdate to write buffered changes to the table. If it's not successful you either need to fix the problems and redo the tableupdate, or you have to do a tablerevert. Transactions will let you do a series of tableupdates. If any one of them fail, then you can rollback the transaction, meaning any successful writes to tables canceled. But the buffers are not changed!

>It seemed to be working fine for awhile, but I probably didn't try adding/canceling a few times in a row when I was initially testing it.
It's probably only lucky, and won't be robust in the field. You might want to test a new version also in two different sessions on your own computer, if you haven't already done so.
Previous
Reply
Map
View

Click here to load this message in the networking platform