"Helen Borrie" <helebor@...> skrev i melding
news:5.1.0.14.2.20030217220637.056ffed8@......

> At 11:37 AM 17/02/2003 +0100, Bj=F8rge S=E6ther wrote:
>
> > > >My SQL was like this:
> > > >
> > > >SELECT
> > > > *
> > > >FROM
> > > > INVOICE
> > > >
> > > >...and the trouble:
> > > >
> > > >Table INVOICE doesn't exist.
> > > >Or - it doesn't have a PRIMARY KEY.
> > >
> > > Well, these are two different problems.
> >
> >I know. But the error message has nothing to do with the underlying

errors=

> .
>
> Bjorge,
> Just to get back on the track and away from your (false) assumption that I
> was telling you
> select * from invoice was invalid sql...
>
> It is NOT what I was saying at all. You said the table INVOICE didn't
> exist. You also left KeyLinksAutoDefine set True for a select on a table
> with no primary key. What I told you (in the initial response) was an
> explanation for why IBO came out with the modified statement as it did. I
> tried to clear up your subsequent misapprehension but it seems to have
> gotten even more bogged down.

The point is, when there is a problem with a table not existing or missing a
primary key that my settings require, there should not be an "Invalid token"
error message. No way. The problem with the missing primary key is actually
*almost* handled by the code, only that it doesn't take the SELECT * case
into account.

Why not just call it an error ?

> You said:
> > I allready found one bug - a TIBOQuery requesting for default values in

a

> > readonly select. In this case I had an extra delay of some 2 seconds -
> > making IBO useless until the bug was located.
>
> Really? What makes you think that TIBOQuery was requesting for default
> values? AFAIK, TIBOQuery doesn't have that capability...I can't make it

do

> that...

I didn't *think*, I *observed*.

From IBODataSet.pas:

procedure TIBODataset.InternalInitFieldDefs;
[...]
{$IFDEF IBO_VCL40_OR_GREATER}
NewFieldDef :=
{$ENDIF}
TFieldDef.Create( FieldDefs,
BDEFieldName,
NewType,
NewSize,
Required and not IsDefaulted, < OBSERVE !!
FieldNo + 1 );
{$ENDIF}

The IsDefault property is the sinner here, as it leads to a call to
SchemaDefaultedCols - which in its turn makes a select call to retreieve
default values.
I believe Jason has allready acknowledged this bug.

BTW, it may be solved with the following modification:

Required and not (ReadOnly or IsDefaulted),


--
Regards,

Bj�rge S�ther
bjorge@haha_itte.no