>Okay so I've got thousands of record changes to make and if anything fails I want all changes reversed. I was doing it fine with full buffering of all the tables involoved, EXCEPT... Some users on Novell are running into error 109 during the final tableupdate() and it seems that when they up the Record Locks in Novell it works but it otherwise fails. But I guess they run into other problems with Novell when they up it so far. Beats me... I don't have a network to play on. I have 113 sites and my boss, not surprisingly, doesn't want to send out an update every time I think it might work next time. The current release is going out without any buffering. I mean, I didn't even know that Novell had the faintest idea of the number of records that VFP was locking. I thought it was an internal VFP job....
> So, does anybody know whether this is a normal problem, and what you are supposed to do about it?
>
> Thanks
> -Adam
Hi Adam,
Novell also has a transaction system but different from FP. FP record locks are controlled by FP. First I should understand something, does this fail only on Novell ? or any multiuser environment. It seems you have an rlock() problem and I expect it to fail on any multiuser environment (to mimic multiuser on one machine you could run the app in several tasks in Win95 or NT). If it fails on any multiuser environment then check :
-Set exclusive is off && Scoped to data session
-Set multilocks is on && Scoped to data session
-A routine doesn't try to have exclusive access to a record locked (ie: in transaction)
Cetin