Subject | RE: [IBO] Re: Master Detail |
---|---|
Author | Helen Borrie |
Post date | 2001-11-15T01:55:52Z |
Olafur,
You seem to have given yourself several problems here.
First, as long as you hold your transaction open and don't commit it, the database changes remain "pending". This seems to be the condition you have created here. The only way your changes will ever commit is when you destroy the form. There is no way to intercept errors because IBO will simply roll back any transaction which it cannot commit. IOW, do not make the committing of the work dependent on the form's destructor. If you have explicit control of the transaction, then you must handle errors and do the conditional try/commit/except rollback stuff in your code.
Second, REPEATABLE READ is entirely the wrong transaction isolation for interactive work. That isolation is for tasks like reporting and data export where you want a process to work with a stable view of the data regardless of changes that were committed since your transaction began.
Third, you didn't mention how you were making the master-detail links. This matters. What are the Mastersource and Masterlinks properties of the detail dataset?
What is the Keylinks property of the detail set?
Also, are you allowing users to enter the data for the keys?
...and see comments below...
At 01:22 AM 15-11-01 +0000, you wrote:
regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
You seem to have given yourself several problems here.
First, as long as you hold your transaction open and don't commit it, the database changes remain "pending". This seems to be the condition you have created here. The only way your changes will ever commit is when you destroy the form. There is no way to intercept errors because IBO will simply roll back any transaction which it cannot commit. IOW, do not make the committing of the work dependent on the form's destructor. If you have explicit control of the transaction, then you must handle errors and do the conditional try/commit/except rollback stuff in your code.
Second, REPEATABLE READ is entirely the wrong transaction isolation for interactive work. That isolation is for tasks like reporting and data export where you want a process to work with a stable view of the data regardless of changes that were committed since your transaction began.
Third, you didn't mention how you were making the master-detail links. This matters. What are the Mastersource and Masterlinks properties of the detail dataset?
What is the Keylinks property of the detail set?
Also, are you allowing users to enter the data for the keys?
...and see comments below...
At 01:22 AM 15-11-01 +0000, you wrote:
>The detail query is open and yes the Commitaction is caClose and here is howTest the .Started property, not .InTransaction
>I open the two query's every time the form gets opened.
>----------
>procedure TfrmFyrirtaeki.FormCreate(Sender: TObject);
>begin
> if not DM2.TActionFyrirtaeki.InTransaction then
> DM2.TActionFyrirtaeki.StartTransaction;That's not strange, it's a reflection of your Isolation setting and (from the code you supplied) because you are not destroying the child forms. Because the only commit is in the child form's destructor, your transaction never commits until your application terminates and cleans up. Simply setting an object to Nil does not destroy it. You must call its Free method.
>
> with DM2.qryMaster do
> begin
> Close;
> Prepare;
> Open;
> end;
>
> with DM2.qryDetail do
> begin
> Close;
> Prepare;
> Open;
> end;
>----------------------
>The strange thing is that after I close and reopen the form I can Insert
>Detail records but they disapear and I don't see any detail records then
>browsing. But if I close the application and run it again then I see the
>detail records.
regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________