This might be DUMB answer but have you looked at the BUG's
of interbase/firebird.

check you SQL statements and make sure they are valid.

I have seen a open bug under firebird
where one query returns no results and
when executed a second time it does return results.

--- In IBObjects@yahoogroups.com, Joe Martinez <joe@j...> wrote:
> I have 3 tables that make up a class registration system. I have
classes,
> sections, and enrollments. One class has many sections. One
section has
> many enrollments. Actually, there's a 4th table: customers. An
enrollment
> is linked to both a section and a customer.
>
> Classes table has a single primary key: classid. Sections has a 2-
part
> primary key: classid and sectionid. Classid is also a foreign
key, which
> references the classes table's primary key. Enrollments has a 3-
part
> primary key: classid, sectionid, and enrollid. Classid and
sectionid also
> make up a foreign key which references the sections table's primary
> key. Enrollments also has another foreign key: customerid, which
> references the customer table's primary key.
>
> Ok. In my app, I have a classes screen and a sections screen. On
the
> classes screen, I have a TIBOTable for the Classes table. On the
screen, I
> show the classes fields, and I have a TDBGrid which shows the
sections for
> that class. I also have a button to add a new section for the
current
> class. On the sections screen, I have a TIBOTable for the Sections
table,
> and I also have a TDBGrid showing all the enrollments. (Both grids
are
> attached to separate TIBOTable objects, set up with the proper
> master-detail properties.
>
> When the user is on the classes screen and clicks the "add new
section"
> button, I switch to the sections screen, and do an Append() on the
sections
> table. The table's OnNewRecord event fills in the section's
classid field
> with the classid of the current class. It grabs the next available
> sectionid for that class, and fills that in as well. It then
leaves the
> record open for the user to fill in the rest of the Section
fields. There
> is a TDBNavigator on the screen, so when the user is done filling
in the
> fields, they click the check mark to save the record.
>
> All this works beautifully almost all the time. But, I've recently
had two
> different customers complain that once in a while on certain
classes, when
> they click the "add new section" button, the new section comes up
with
> customers already enrolled in it! This did not seem possible to
me, given
> the key structure that I have set up, so I had one of them go
through it
> with me on the phone. Here's what we observed:
>
> Go to the class and click on Add New Section.
> Section #16 is added, but it's enrollment grid is already populated
with 5
> customers.
> Click on the checkmark to save the section. The record (section
#16) is
> posted successfully.
> Go back to the Classes tab (same class), and click Add New Section
again.
> Section #17 is added, and it's enrollment grid is already populated
with
> the same 5 customers.
> Click on the checkmark to save the section. The record (section
#17) is
> posted successfully.
> Repeat two more times for sections 18 and 19.
> Go back and check all 4 sections. They ALL have the SAME 5
students in
> them!?!?!?
>
> This does not seem possible, given my key structure. The
enrollment grid's
> table's master-detail relationship is based on the section's
classid and
> sectionid. If these are all the same enrollment records on each
section,
> they should only be able to link to ONE section, yet each section
has a
> different sectionid. But there they are.
>
> I had the user exit my app and go back it. We found that all 4
sections
> were still there, but the "phantom" enrollments were all gone from
the
> grid, as they should be.
>
> The customer was happy with that, but I promised that I would get
to the
> bottom of why it happened. I can't figure it out. As I said, it
has
> happened to another customer of mine as well, so I need to get it
fixed.
>
> Any ideas?
>
> -Joe