At 07:49 PM 7/31/2003 +1000, you wrote:

>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?

Yes. These are the values for the primary key. The name of the primary
key column is PRODBARCODE and is of type VARCHAR(25).

> >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?

Yes.

> >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.

What I mean is, for example, if instead of setting the SQL to:
Select * from products where PRODBARCODE = 'KBSolidRED'

I instead set it to:
Select * from products where PRODBARCODE = 'KBSolidWH'

The first case generates an AV. The second case doesn't generate an AV,
but displays the record correctly.

> >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).

Here it is:

CREATE TABLE PRODUCTS (
PRODBARCODE VARCHAR( 25 ) NOT NULL
, PRODDESC VARCHAR( 255 ) NOT NULL
, PRODPRICE DOUBLE PRECISION NOT NULL
, PRODTAX VARCHAR( 1 )
, PRODINVENTORY DOUBLE PRECISION NOT NULL
, PRODWARNING DOUBLE PRECISION
, PRODDEPT INTEGER
, PRODWANTED DOUBLE PRECISION
, PRODSOURCE VARCHAR( 80 )
, PRODPARTNO VARCHAR( 50 )
, PRODCOST DOUBLE PRECISION
, STOREID INTEGER NOT NULL
, PRODSERIALIZED VARCHAR( 1 )
, PRODASKQTY VARCHAR( 1 )
, PRODTAX2 VARCHAR( 1 )
, PRODTAX3 VARCHAR( 1 )
, PRODDISCOUNTABLE VARCHAR( 1 )
, PRODLOCATION VARCHAR( 50 )
, PRODACCMONEY VARCHAR( 1 )
, PRODACCVOLUME VARCHAR( 1 )
, PRODPRICE2 DOUBLE PRECISION
, PRODPRICE3 DOUBLE PRECISION
, PRODNOTES VARCHAR( 2000 )
, PRODLASTCOUNT DATE
, PRODAVGCOST DOUBLE PRECISION /* Computed */
, CONSTRAINT PRODUCTSPK
PRIMARY KEY ( PRODBARCODE )
)