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

What I meen is: I have executed a query returning X rows. In my application
I have a visual control that can displays the row data, but only Y rows at a
time. A scrollbar will appear in the visual control when Y is smaller than
X. The scrollbar desides which row to show at the top of the visual control.
The visual control needs continiously to update the visible rows when ther
user pulls the scrollbar. This is why I need to locate a specific row
number.

For example: I have a statement containing 10000 rows. The scroll bar of the
visual control is pullet to position 6000. Now I need to locate row number
6000 and fetch data for the next 25 rows (or how many that can be desplayed
in the visual control).

-
SMN

> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: 26. maj 2003 12:09
> To: ib-support@yahoogroups.com
> Subject: RE: [ib-support] Absolute addressing of rows in a previously
> prepared and executed DSQL statement
>
>
> 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.
>
>
> 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
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>