Problem with a memo field in multiuser environment

[CBU64]

Hi everybody!

I've having problems with a memo field. I have an app designed to work in a multiuser environment (via shared files) thru a form that contains a button that in its click event, among other things, enables controls associated with their corresponding fields and executes the following code:

...
begin transaction
append blank
...

Another pair of buttons do their counterpart tasks: depending whether the user decides to cancel the transaction (rollingback and disabling controls code) or accepting it (ending transaction and disabling controls code).

All my tables are buffered in optimistic row mode (mode 3) via dataenvironment properties and the form has no buffer mode.

The form has private data session (value 2 in its property chart).

Everything works fine until one user begins the append transaction, reaches an editbox (associated with a memo field), changes focus out of it while another user begins the same transaction (appending a blank record within a transaction). The second user gets a message in the status bar notifying Record no available ... Please wait.

What am I doing wrong? Have I missed something about VFP concurrent programming? Do I need to make an extensive use of file/record locking within my app? Take away all the buzz of this biz and what do you get? 01000100101010...

 

[csvideo]

I don't realty understand the real problem, however, in all the APPs I have developed before I used optimistic table buffering mode (mode 5) and they worked fine in a multiuser environment. Try optimistic table buffer (mode 5).

 

[thatguy]

Hey there CBU!

I'm a bit new to table buffering, but from what I've seen, begin/end transactions are mainly used during referential integrity functions. For instance, in my database stored procedures, when a user appends/changes/deletes a record, i begin a transaction, check all the child tables, add/change/delete child records accordingly and end the transaction - all programatically, so the transaction lasts only a millisecond. The help file for BEGIN TRANSACTION says this:

When you modify records in a table that is part of a transaction, other users on the network do not have access (read or write) to the records until you end the transaction.

When other users on the network try to access records you have modified, they must wait until you end your transaction. They receive the message "Record not available ... please wait" until the records become available. Because of this, it is important to keep the length of the transaction to a minimum or conduct the transaction during times when others do not need access.
​

To avoid this, i use table buffering, and when the user moves off a record, i call a save function in a controlling business class for that view that either calls tableupdate() or tablerevert().

Again, i'm a bit new to buffering and multiuser env's, but this seems to work well. I hope it helps!

-- michael~

PS.-i'm also new to using colors in my posts! s-)

 

[chpicker]

I tried something similar to this last week, and here were my observations.

When you issue BEGIN TRANSACTION, VFP locks all records you access until you either END TRANSACTION or ROLLBACK. If you issue an APPEND BLANK, then it locks the new record, preventing anyone else from APPENDing a BLANK record. (They are all trying to APPEND the same record). Since this record doesn't actually exist, I assume that it actually locks the table header, but the effect is that only one user can have an APPEND issued within a transaction at the same time. Others can EDIT records no problem, but they can't add new ones until the first user ends or rolls back the transaction.

 

[DEDMOD]

The point being that you should never have user input during a transaction. When the user hits a button saying something like 'save data' or 'enter transaction', that's where her interaction is finished. When youlre ready for more interaction, the transaction should be finished. Failure to plan things this way is just asking for trouble.

Dave Dardinger