I have logged the issues here as items to be fixed or improved.

Is there anything that you are yet unsatisfied or clear on a functional
work-around?

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --


"Bj�rge S�ther" <bjorge@...> wrote in message
news:b2qjgk$c30$1@......

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