Ann:

Thanks loads, for the "kick in the head" helped! :D

I had been using the "built-in/native" functions of C++ for years (e.g. Tablename->Append(), etc), so this wasn't an issue.

The minimum I had to put in, on the aux table screen was:

DataModule2->IBTransaction1->CommitRetaining();

If I used

DataModule2->IBTransaction1->Commit();

Every thing would close.

Just to be safe in the main processing screen, I added:

if (DataModule2->IBTransaction1->InTransaction == true)
{
DataModule2->IBTransaction1->Commit();
}

Just before I started.

I had a problem yesterday using a COMPLEX query, but it very well might be this that was causing me the problem. I'll check it out, probably Wednesday (I'm rebuilding my computer (software wise) tomorrow).

Thanks loads again for the "kick in the head"! ;D

--- In firebird-support@yahoogroups.com, "Ann W. Harrison" <aharrison@...> wrote:
>
> On 1/10/2011 4:33 PM, munster77054 wrote:
>
>
> What you've left out is where you start and end transactions and
> what transaction modes you're using.
>
> > Ok, I know this isn't 100% Firebird, but maybe one or more of you fine folks can help me. Here is the situation:
> >
> > 1. I have a Borland C++ program that has three main tables.
> > 2. One table is the "main" tables.
> > 3. The other two are aux tables.
> > 4. One of the aux tables, has a list of parameters that specify what is records are deleted DELETED in the main table... for instance all records containing "HEALTH LAW".
> > 5. Now in my program, I have a screen that allows the user to put in the parameter into the aux table.
> > 6. The user can access #5 from the main screen.
>
> Fine, reading what was created in its own transaction.
>
> > 7. If the user accessed the aux screen, adds the record in, it saves it just fine.
>
> Probably from another transaction and connection.
>
> > 8. Then the user goes back to the main screen, and tells the program to process the records in the main table, deleting the records specified by the parameters in the aux table.
> > 9. Here is the gotcha, and I think it is a Firebird issue, that is why I'm asking it here.
> > 9.1. After the parameter is added, I can verify that it is in the table via a gui.
> > 9.2. I then close the aux screen and return to the main screen (after closing the gui).
> > 9.3. I tell the program to run the deletion routine.
> > 9.4. It runs, but doesn't delete the record(s) requested.
>
> Probably that runs in an old transaction that cannot see the newer
> record.
>
> > 9.5. I then attempt to verify that the parameter still exists in the parameter table, but it doesn't. The deletion routine only does a query of aux table (select field from table).
> > 9.6. I repeat the adding of the parameter, but this time, shut the program down.
> > 9.7. I start the program and go to the main screen.
> > 9.8. I tell the program to run the deletion routine.
> > 9.9. The requested record(s) in the main table are deleted, and I then check out the parameter table, and the parameter is still there.
> >
> > Does anyone have any idea what is happening? I checked the cache settings, and the program writes the records directly to disk, which tells me the the buffers are clear. Any ideas?
> >
>