Subject | Re: [IBO] CachedUpdates |
---|---|
Author | Randal W. Carpenter |
Post date | 2007-06-27T19:31:31Z |
On Mon, 25 Jun 2007, Stephen Boyd wrote:
leave updates applied without following with a commit sequence. (sorry I use
c++ builder so the syntax is slightly different
but its similar enough to figure out I hope):
if(!FairBase->InTransaction) FairBase->StartTransaction();
try
{
LoadQuery1->ApplyUpdates(); // try to write the updates to the database
FairBase->Commit(); // on success, commit the changes;
}
catch (...)
{
FairBase->Rollback(); // on failure, undo the changes
throw; // throw the exception to prevent a call to CommitUpdates!
}
LoadQuery1->CommitUpdates(); // on success, clear the cache
Short of that, Several things you need to be aware of though, when I converted
one of my larger applications I saw quirks with cached updates and queries in
general. ApplyUpdates seemed to work though, I can't recall any major issues
anyway. Here is what I did to fix it various problems...maybe I accidentally
fixed ApplyUpdates along the way...
1. If you close and re-open a query to read new data, you have to do an
explicit CancelUpdates then close and re-open it.
CustMod->CustQ1->CancelUpdates(); // needed for ibo to play nice
on cached update queries
CustMod->CustQ1->Close();
*** maybe Do some stuff here, maybe not***
CustMod->CustQ1->Open();
2. I find that moving the updateobject sql that you created under the sql query
itself (noticed that update is renamed to edit...the others are named the same)
and getting rid of the update object will clear up many
quirky issues...this may very well fix you up.
3. Be sure you add your keylinks to queries especially on queries that access
more than one table...that is simple a list of appropriate keys for the
query...very important.
4. If you edit the sql of a query at any point, you should now use an
->InvalidateSQL method on the query...for instance
LoadQueryCheck->SQL->Clear();
LoadQueryCheck->SQL->Add("SELECT SHIPPER_NO FROM LOAD WHERE (SHIPPER_NO
= :ShipNum)");
LoadQueryCheck->InvalidateSQL(); // needed for ibo on changes to sql
statements
5. If you use any unnamed fields that are access as COLUMN1, COLUMN2, etc...the
bde starts numbering these at 1, ibo starts numbering them at 0...this can be
very hard to find. I went back and used an "as" clause to name these unnamed
queries...besides its prettier anyway.
Let me know if that helps, otherwise post an example...I will try to see if it
does the same for me.
Oh and I am using IBO 4.7.16 so my issues and yours may not be the same :)
Randal
> I am converting a BDE application to IBO 4.5B with Delphi 5. I amNot sure myself. I do a commitupdates during the commit phase...and I rarely
> having problems with cached updates. The first time I Post to an
> IBOQuery the UpdatesPending flag gets set to True just as it should.
> I detect this and call ApplyUpdates to write the changes to the
> database. However, the second, and all subsequent, times that I post
> to the IBOQuery the UpdatesPending flag is not set to True. As a
> result, the changes never get written to the database. This all
> worked perfectly using BDE and I have made no code changes beyond the
> changes required to the .DFM files to convert from the BDE components
> to IBO.
>
> Does anyone have any idea what might be causing this?
>
>
leave updates applied without following with a commit sequence. (sorry I use
c++ builder so the syntax is slightly different
but its similar enough to figure out I hope):
if(!FairBase->InTransaction) FairBase->StartTransaction();
try
{
LoadQuery1->ApplyUpdates(); // try to write the updates to the database
FairBase->Commit(); // on success, commit the changes;
}
catch (...)
{
FairBase->Rollback(); // on failure, undo the changes
throw; // throw the exception to prevent a call to CommitUpdates!
}
LoadQuery1->CommitUpdates(); // on success, clear the cache
Short of that, Several things you need to be aware of though, when I converted
one of my larger applications I saw quirks with cached updates and queries in
general. ApplyUpdates seemed to work though, I can't recall any major issues
anyway. Here is what I did to fix it various problems...maybe I accidentally
fixed ApplyUpdates along the way...
1. If you close and re-open a query to read new data, you have to do an
explicit CancelUpdates then close and re-open it.
CustMod->CustQ1->CancelUpdates(); // needed for ibo to play nice
on cached update queries
CustMod->CustQ1->Close();
*** maybe Do some stuff here, maybe not***
CustMod->CustQ1->Open();
2. I find that moving the updateobject sql that you created under the sql query
itself (noticed that update is renamed to edit...the others are named the same)
and getting rid of the update object will clear up many
quirky issues...this may very well fix you up.
3. Be sure you add your keylinks to queries especially on queries that access
more than one table...that is simple a list of appropriate keys for the
query...very important.
4. If you edit the sql of a query at any point, you should now use an
->InvalidateSQL method on the query...for instance
LoadQueryCheck->SQL->Clear();
LoadQueryCheck->SQL->Add("SELECT SHIPPER_NO FROM LOAD WHERE (SHIPPER_NO
= :ShipNum)");
LoadQueryCheck->InvalidateSQL(); // needed for ibo on changes to sql
statements
5. If you use any unnamed fields that are access as COLUMN1, COLUMN2, etc...the
bde starts numbering these at 1, ibo starts numbering them at 0...this can be
very hard to find. I went back and used an "as" clause to name these unnamed
queries...besides its prettier anyway.
Let me know if that helps, otherwise post an example...I will try to see if it
does the same for me.
Oh and I am using IBO 4.7.16 so my issues and yours may not be the same :)
Randal