At 02:01 AM 19/10/2006, you wrote:

> > I'm dubious about the above - it's part of the Metadata
> > components...however, perhaps that's what you're working with. I
> > just can't find a public declaration for that function.
> >
>
>it's my own function that creates and assigns a TIB_Cursor properties
>for easier coding.
>
> > RecordCount is meaningless. An IB_Cursor doesn't know about it. It
> > has a single-row buffer.
>
>Ouch... then why is it a public property?

It's there for compatibility with the VCL. As you fetch each row
into the row buffer, the RecordCount will get incremented. Therefore
it can only ever tell you how many rows it has fetched so
far. Calling Last will get "something like" the theoretical number
of rows in the set; but if you inserted or deleted any rows en
route, the RecordCount won't be accurate.

If you call Open on a TIB_Cursor, no records are fetched, so the
RecordCount is zero.

With buffered sets (TIB_BDataset descendants) the RecordCount
represents the number of records fetched into the dataset buffer so
far, so it's not a count of all the records in the set, either, until
the last record has been fetched.

> > Also, you don't need SELECT FIRST in your SQL. A domain has only
> > one record in RDB$FIELDS. If you actually want to target the first
> > validation rule in the blob, you'll need to process the stringlist
> > string-by-string in some fashion.
>
>My thinking was for efficiency--that FB would stop looking as soon as
>it found the first item--rather then always searching for a single
>domain. Make sense?

No. That's "Paradox-think". SELECT FIRST is inefficient as the
engine has to form a set in order to decide which one is
"first". It's going to do the WHERE search anyway, so for a search
on a unique key, a straight SELECT is the minimal approach.

Helen