TIB_Cursor is slightly faster, but you can only use it if unidirectional
navigation will suffice. For bidirectional navigation, use TIB_Query.

Normally you would want to specify a where clause in your query to get only
the record(s) of interest, preferably where some of the fields are covered
by indices. A select without a where clause goes against Client/Server
methodology - let the server do the work and don't transfer any records you
won't need.

TIB_Cursor and TIB_Query are fairly similar to TIB_DSQL in the way you work
with them, prepare them, assign parameters and call First (calling Open,
then First will just consume extra time) and step through the records
calling Next. After closing the query, just assign parameters and call
First again if you want to.

HTH,
Set

Under development for one tear - that doesn't sound all to bad considering
the huge requirements you're up against ;o)

At 11:02 01.02.2001 -0000, you wrote:

>The program is a simultator that does some heave calculations based
>on the data in the database. Only the calculation does take 20 sec...
>This is a real program that very few companies will work with (on
>order so far). It's I and two other guys that work with the program.
>
>The program have been uder development for one tear and I have only
>been in to it the last two months, so I'm not totally clear on every
>detail.
>
>I have managed to fix the writing problem now. Using the DSQL
>component did cut the writing time to 15-20 sec instead of 6-8
>minutes. Now is all the reading the problem. It takes 45 seconds to
>read from the database, using the TIB_Query.
>
>Our goal is that the simulator will run all the time in the program.
>Now do you have to start the simulator and then wait for it to run
>and then continue to work with the program.
>
>Now my question!!!
>Is the TIB_Query the fastest TQuery-alike component to use when
>you're going to read from the database. Because itäs the components
>that I'm using now.
>
>--- In ib-support@y..., Olivier Mascia <om@t...> wrote:
>> Yes, I understand your idea Simon.
>> (Didn't wanted to be rude with you, but I really thought it was a
>joke :-)
>>
>> Your '15,000 rows a second' problem should be clearly defined and
>exposed
>> in detail before anybody can try to give you valid recommendations.
>>
>> We know you talked about 15,000 inserts a second.
>> We do not know the exact structure of that row.
>> We do not know if you have to sustain a rate of 15,000 rows a
>second ?
>> For how much time ?
>> Or are these bursts every other minute ?
>> Where does that data come from ?
>> Produced by the program itself ? Read from some peripheral ?
>> Or from the LAN ? Will the source of the data itself even sustain
>the
>> 15,000 rows a second ?
>> Is this idea of inserting 15,000 rows a theorical exercise for
>you ? Or do
>> you even have a real case ?
>>
>> I am willing to help within my knowledge limits, but I'd sincerely
>would
>> like the problem to be real a "real life" case and not just a
>hypothetical
>> query. At least I first would like the problem to be clearly and
>completely
>> defined.
>> Else we will loose much precious time, you, me and others.
>>
>> The very basic recommendation would of course be to get decent cpu
>power
>> (single processor), very fast ram, very fast SCSI I/O controller,
>excellent
>> disks, maybe in a striping configuration or RAID 0+1 configuration
>> depending on the added I/O speed wanted and/or protection.
>>
>> Olivier.
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>