> SELECT SINGULAR would in fact be the "most right" kind of select query to
> use in this case, since it won't return any exceptions. All you'd have to
> do is the equivalent of an IsEmpty test on Fields[], right? What would
> that test be? since TIB_DSQL doesn't have the BOF and EOF properties...

I don't think SINGULAR is a keyword that goes in the statement if that's
what you are implying by the caps. There is no test with TIB_DSQL. You
either get information from one row back or an exception.

> Users will still need to know that this applies only to Firebird 1.5 and
> later, until (or unless) the fix is backported in the Firebird 1.0.4
> subrelease...

I can't remember exactly when this fix was introduced. It may also be in
Firebird 1.x. It had to do with the SQLDa buffer in the client getting
scrambled due to a variable that got bumped around instead of staying
dedicated to one statement context.

Jason

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, July 03, 2003 3:34 PM
Subject: Re: [IBO] How To Know, Whether TIB_DSQL has returned any records or
not ?


> Jason,
>
> At 09:42 AM 3/07/2003 -0700, you wrote:
> > > while using select statement with TIB_DSQL is ther any way to know
that it
> > > has returned any records or not
> > >
> > > i m getting an following error if my select doesnt return any records
> > > and if i use RowsSelected
> > >
> > > "SELECT GROUPID FROM GROUPINFO WHERE GROUPNAME = ?AGroupName"
> > >
> > >
> > > ISC Error Code = 335544374;
> > > Error message = "attempt to fetch past the last record in a record
> >stream";
> >
> >TIB_DSQL is an ideal component for doing this kind of select now that the
> >bug in InterBase that caused problems doing this is fixed in Firebird.
> >
> >If it succeeds without an exception then you are assured that it fetched
one
> >and only one record.
> >Not zero and not more than one.
> >
> >When using TIB_DSQL it performs a singleton select rather than a cursor
> >based select, therefore it is more efficient since a cursor doesn't have
to
> >be created on the server.
>
>
> regards,
> Helen