Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Graham Brown
  Where is Graham Brown?
 East Midlands
 United Kingdom
 Graham Brown
Subject: Locking and cursoradapters (revisited)
Thread ID: 78516 Message ID: 78516 # Views: 3 # Ratings: 0
Version: Visual FoxPro 8 Category: Databases, Tables and SQL Server
Date: Tuesday, October 04, 2005 6:38:06 PM         

Hi all

I posted this one earlier in the year about the following code failing and giving the same order number to two different records. I've also taken Andy's comments on-board about checking the return value but am confused about locking a cursoradapter.

Everything has been fine since february but have just had a call from the customer with two duplicated order numbers.

In this instance the ca is to a vfp table so should I issue an rlock against the underlying vfp table. Is that the best practice for doing this?

Would the alternative be to use pessimistic locking on the parameters table instead of optimistic as I do now. I haven't used pessimistic locking in any of the vfp projects I've done so am not sure what the implications of this are.

Appreciate any pointers.


Hi Graham

> When I do a tableUpdate does the change get written back immediately to the DBF?
> What I have is a networked application using cursoradapters, the form has a save button which gets the latest order number from a parameters file then writes back the data with tableUpdate()
> The code for this is something like: -
> thisform.oDataEnvironment.Parameters.CursorFill() ' Make sure I have an up to date version of the parameters file
> nOrder=parameters.NextOrder
> replace parameters.NextOrder with Parameters.NextOrder+1
> sele Parameters
> =TableUpdate(.t.)
> replace orders.nOrder with m.nOrder
> sele orders
> =TableUpdate(.t.)

> When this code is run on a network I sometimes get two order file records with the same number the problem does not happen on every order.

I am not surprised you have two critical errors in the code you posted:

First, But since you are not locking the Parameters table, what is to stop two users getting, and saving the same 'next' number? Nothing as far as I can see.

Second, Since you are not checking the reurn value of TabvleUpdate() how do you know your update succeeded?

> I know I can move the order generation to the default entry on the field but would rather not at this point.

That's your decision. But if you insist on doing it this way then you need to fix the two errors you have in your code.

=> You must lock the Pareameters table while you increment the number and save it to prevent other users generating and using the same 'next' number.
=> You must check that your lock request succeeds and handle the scenario where another user has the record locked (i.e. where you will not be able to get a lock)
=> You must check the return value of TableUpdate to ensure that your update HAS succeeded before you release the lock

> Anyone any ideas why this code might fail?

To be blunt, yes! It's not good code - especially in a multi-user environment.

Andy Kramek
Microsoft MVP (Visual FoxPro)
Akron, OH, USA


Locking and cursoradapters (revisited) Posted by Graham Brown @ 10/4/2005 6:38:06 PM