At 11:20 PM 16/06/2008, you wrote:

>Hi there ,
>
>fb 2.1
>
>we have a program it works as server /client.my problem is when i user
>in edit(append or insert) mode in the database if another user wantto
>be in edit(or append or insert) it says Lock conflict .....

This is not a problem: it is concurrency in action. Your application should intercept lock conflicts and deliver a message and a way to deal with them.

>the program gives this information even the users are not on the same record? im confused about this error.

You will be less confused when you understand that updating, inserting and deleting occur in two stages: until the transaction is committed, changes or deletions are visible only to the transaction that performed them; changed or deleted records are locked and will remain so until the transaction is either committed or rolled back.

If another transaction is In snapshot isolation ("concurrency") or in all settings except one for read committed isolation, there is still a lock conflict after the commit if that other transaction started *after* the transaction that had the lock.

>is there a solution?

Repeat, a lock conflict is not a problem. It happens intentionally, to prevent transactions from overwriting the work of other transactions. The "solution" is have your application handle concurrency properly. You really need to understand how transaction isolation works, along with the various other settings you can apply (WAIT/NO WAIT lock resolution, [NO] RECORD_VERSION for Read Committed) and handle each possible type of lock conflict appropriately in your application code.

>i set the transactions after insert or append but at least it gives this information.

"set the transactions"? What does this mean?

By the way, "append" is not a Firebird concept. In Firebird, INSERT always appends rows to a table. There is no APPEND statement.

./heLen