Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Data Buffering, Pessimistic & Optimistic locking and suc
Message
From
13/12/2006 18:27:36
Mike Yearwood
Toronto, Ontario, Canada
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01177438
Message ID:
01177441
Views:
13
>My apologies if I am in the wrong area. This is my first post and deals with a subject that most may have already mastered.
>
>I am trying to expand my horizons into the world of data buffering. My current application depends on rlock() and flock() for table updates. I reserve the record(s) when editing begins by storing user name in an inuseby field and then scatter memory variables. When ready to save I lock the record, gather the changes, unlock, and then release the inuseby field. You know, the old way of doing things.
>
>I think I understand how changing 1 table only can be done using the Optimistic Table Buffering. Where I am running into a wall is on a form with several tables being updated at once.
>
>For example, I have a order entry form that uses a header table and a detail table. The user enters the order info and then adds items for the order. The items are pulled from an inventory table. When the order is saved the customer table is updated with new balance totals and the inventory table is updated with new allocation and on order amounts.
>
>Without continuing to reserve the order record using the inuseby field, what is the accepted method of updating all tables using optimistic table buffering. Ideally, I don't need user 2 to be able to begin an edit on the order while user 1 is in the middle of modifications. Is pessimistic record buffering a viable option in this case? Wouldn't that prevent new records from being added?
>
>If more information is necessary please let me know. I have about 10 users who are adding orders on a continuous basis. These same orders are being accessed by 5 users in the shipping department. And the inventory and customer tables are accessed by all 40 users on the system. Having a user add 10 line items and then rolling back their additions because someone else is on the same order is really not an option.
>
>TIA for your help and please be patient with this novice.

You set optimistic table buffering for all the tables you want to update. When the user hits save, you ...

Bear in mind this is for demonstration.
BEGIN TRANSACTION

SELECT ALIAS1
IF NOT TABLEUDPATE(.T.,.T.)
  AERROR(LAERROR)
  *Display message somehow.
  ROLLBACK
  RETURN .F.
ENDIF

SELECT ALIAS2
IF NOT TABLEUPDATE(.T.,.T.)
  AERROR(LAERROR)
  *Display message somehow.
  ROLLBACK
  RETURN .F.
ENDIF
END TRANSACTION
RETURN .T.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform