Subject | Re: [firebird-support] Update & Syncronization prpblem |
---|---|
Author | Helen Borrie |
Post date | 2003-09-01T05:05:18Z |
At 11:27 AM 1/09/2003 +0700, you wrote:
view of the data. Your application is responsible for this requerying -
the server does not do it.
If the other client's transaction is Snapshot ("Concurrency") then
CommitRetaining will not be enough to give it access to changes by other
transactions. CommitRetaining causes the existing transaction context to
be retained, i.e. your user will not have access to work committed by
others until her application has performed a hard Commit.
knowledge if you are going to work with Firebird.
heLen
>Hello,No, the other client only has to commit its transaction and requery its
>
>I have a newbie problem using Firebird here,
>let say i have 2 client using same database, after the first client
>inserting new data into a table,
>the other client cannot read the new data directly.
>
>Seems like both of them having separates server, I have tried with COMMIT
>& COMMITRETAINING but still the new data couldn't be read from another
>client. So, in order to be able to read the new data, the other client
>have to Disconnect and then relogin to the server.
view of the data. Your application is responsible for this requerying -
the server does not do it.
If the other client's transaction is Snapshot ("Concurrency") then
CommitRetaining will not be enough to give it access to changes by other
transactions. CommitRetaining causes the existing transaction context to
be retained, i.e. your user will not have access to work committed by
others until her application has performed a hard Commit.
>Is there any solution for this problem.Study the literature regarding transaction isolation. It is essential
knowledge if you are going to work with Firebird.
heLen