>Suppose a situation :
>- a header-detail form (1 to many as you wish)
>- detaillines are created with a primary key that is a simple integer, which comes from some counter-table
>- Transactions are used so if the user decides to cancel, the entries can be rolled back
>
>The problem is :
>2 simultanous users can't use this form because the record holding the detailline number (its pimary key) is kept locked during the transaction.
>
>Any suggestions ???

Pascal,

Okay, this is several steps of explanation.

1) Don't use the tables directly. Use parameterized local or remote views of the data and open in buffered mode. This does a couple of things. First, it protects your data. Two, it allows you to limit the amount of data the engine has to juggle, and VFP likes small bites of data.

2) Create a trigger in the stored procedures for your DBC that selects the highest value of your integer primary key, increments it by one and returns the new value. Use this trigger to set the default value for your integer primary key column. The one we use is called newid, and takes two parameters, the name of the table, and the primary key column.

What happens is this; When you have a view open in buffered mode and append a blank record, the record is appended to the view only. You then edit the new record in the view. When you are ready, issue a tableupdate(). The engine adds a record to the table, and the trigger automatically fires, dropping the new value into the primary key column, the rest of the columns are written by the tableupdate(), and you're done. If the tableupdate fails for any reason, you can tablerevert() and throw the record away in the table. Very simple, very quick, and with 80+ users on an app, it never misses.

Regards,

Jason