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.