At 11:35 AM 26/05/2003 +0200, you wrote:

>Hi
>
>Thanks for the answer.
>
>1) Well I think he is hiding something from you. :-) The following is from
>the IB6.0 API reference:
>
>---->
>isc_dsql_fetch()
> Retrieves data returned by a previously prepared and executed DSQL
>statement.
>
>Description isc_dsql_fetch() retrieves one row of data into xsqlda each time
>it is called. It is used in
>a loop to retrieve and process each row of data for statements that return
>multiple rows
>in a cursor.
>
><----

Erm, I think the confusion is coming from the name "DSQL", which is just
the abbreviation for "Dynamic SQL" - that is, it refers generically to any
statement that is not static SQL or a PSQL extension. The fact that IBO
has a component called "TIB_DSQL" that encapsulates a "bare" executable
statement is a red herring.

>2) My problem is that I wish to display the result of a query in a visual
>control. In my case the rows of interest can be several thousands. When the
>user scroll the control I need to be able to display the rows which are
>visible. This is why I wish to be able to fetch a specific row from the
>query.

Sorry, but to me these two case descriptions are contradictory, at least in
the context of single DSQL statement. If your statement displays thousands
of rows, then it cannot also display only one single row. You would need
two statements: one that outputs the thousands of rows {{{shudder}}} and
the other that has a parameterised WHERE clause to pinpoint one single row
by its primary key. In two statements inside a single transaction, they
are not contradictory.

So, your dataset would be output from e.g.
SELECT FIELD1, FIELD2, FIELD3 FROM ATABLE

and your singleton row would be output from
SELECT FIELD1, FIELD2, FIELD3 FROM ATABLE
WHERE PKFIELD = :PKFIELD

or would be absolutely positioned in a DML statement with e.g.

UPDATE ATABLE
SET FIELD2 = <somevalue>
WHERE PKFIELD = :PKFIELD

Deducing from your requirements, presumably your user picks one row that
she wants to operate on. Your application picks up the value of the
primary key on that row and passes it to the parameter :PKFIELD.

>I have looked at the implementation of the InterbaseExpress
>TIBDataSet component, and it looks like it handles the problem by caching
>all of the rows in memory! This dosn't seem to be a good solution to me...

If you specify an unrestricted query and you need your application to have
access to all and any rows in that output set, you are going to have to
cache the rows somewhere. They are cached on the server until your
application starts fetching rows. The TIBDataset component handles fetches
in a fairly "raw" way and relies heavily on pulling everything across and
caching the rows in concrete boots.

Some other components focus intensely on giving you a high degree of
control over the number of fetches and the synchronisation of client
buffers with the rows still waiting on the server. IB Objects, for
example, uses two cursors on large sets, splitting the rows "above" the
user window and those "below" it in a mixture of genius and wizardry known
as "Horizontal Dataset Refinement" (HDR). This keeps traffic low and
transactions short - two essentials for efficient client/server processing.

If you are doing this yourself at the API level, you'll have to write code
to get this kind of control. It is no mean feat. You really have to WANT
this massive scrolling interface pretty bad.

Oh, just to target your Subject, "absolute addressing of rows" in any SQL
dataset - whether it is a table (for searched DML) or an output set - is by
uniquely seeking the row by its primary key...

heLen