At 02:29 AM 31/07/2003 -0700, you wrote:

>I have a table (Products) with the following keys:
>
>KBSolidVO
>KBSolidWH
>KBSolidBK
>KBSolidRED
>KBSolidsIND

Are these values for the primary key? What is the name and data type of
the primary key column?

>I have verified this with other tools, so I know that these are correct.

Do you mean that you have verified that there are five records in Products,
whose primary key values are those listed above?

>In my app, I connect a TIBOTable to this table, and connect the TIBOTable
>to a Grid. I open the table, and it shows the following keys:
>
>KBSolidBK
>KBSolidBK
>KBSolidWH
>KBSolidsIND
>
>(Yes, it shows KBSolidBK twice, and doesn't show KBSolidVO or KBSolidRED
>at all)
>
>Ok, now I have a TIBOQuery. I attach it to the same TIBOGrid. I set the
>SQL to:
>
>select * from products
>
>Here are the keys that I get in the grid:
>
>KBSolidVO
>KBSolidWH
>KBSolidBK
>KBSolidsIND
>
>So, in this case, BK is only there once, and VO is back, but RED is still
>missing.
>
>Final test. Still use TIBOQuery attached to the grid. I set the SQL to:
>
>Select * from products where PRODBARCODE = 'KBSolidRED'
>
>When I open the query, I get an Access Violation.

You don't get an AV from merely opening a query that returns no
records. You *will* get an AV from referring in code to an object that
isn't instantiated (never was, or has been destroyed). There's a bunch
here you aren't telling.

> I DON'T get the access violation if I search on one of the other keys.

I don't understand this statement "search on one of the other keys". If
these are all members of the primary key set, then searching will find a
member that exists and will not find one that doesn't exist.

>Does anyone know what's going on? Is it a bug in IBO? I'm using
>IBO2.Gc. I've thought of upgrading, but before I do, I'd like to know if
>this is a known bug or not.

It doesn't sound like a "known anything". Could you answer the questions
and also show the DDL for the Products table (including the primary key
definition).

Helen