Subject | Re: [IBO] Big Batch... |
---|---|
Author | Admin |
Post date | 2001-03-16T21:02:42Z |
Jason -
All that I can tell you from the minimal depth that I understand this
from is that the DSQL component didn't get the job done any faster than
a TIBOQuery, TIBOTable etc. I'm trying to find a strategy to make this
fast. 14,300+ is a big number, but the actual quantity of data is small
- one column of 9 characters in a CHAR column in a dialect 1 database.
There ought to be a way on the database side to make this extremely
fast. However, the data originates on the internet, where I download
csv's from. Then my delphi code parses out the symbol data into
TStringLists, and from there it goes into the database.
I noticed that when I did this with a Paradox table it was many times
faster. Perhaps that's the best approach...
Thanks again.
David Keith
Jason Wharton wrote:
Please review the attached resume and skills narrative in consideration
for the position of , and contact me at your earliest convenience.
Thank you.
David Keith
[Non-text portions of this message have been removed]
All that I can tell you from the minimal depth that I understand this
from is that the DSQL component didn't get the job done any faster than
a TIBOQuery, TIBOTable etc. I'm trying to find a strategy to make this
fast. 14,300+ is a big number, but the actual quantity of data is small
- one column of 9 characters in a CHAR column in a dialect 1 database.
There ought to be a way on the database side to make this extremely
fast. However, the data originates on the internet, where I download
csv's from. Then my delphi code parses out the symbol data into
TStringLists, and from there it goes into the database.
I noticed that when I did this with a Paradox table it was many times
faster. Perhaps that's the best approach...
Thanks again.
David Keith
Jason Wharton wrote:
>--
> No, you should not use stringlists like that. Unless it is just one row at a
> time that is.
>
> The most important difference between a buffered dataset and the TIB_DSQL
> component is that you are not buffering up the records as you send them to
> the server. Therefore you are using much less memory. To buffer inserts as
> they are happening is unwise in most all cases.
>
> HTH,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
> ----- Original Message -----
> From: "Admin" <dkeith@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Friday, March 16, 2001 12:52 PM
> Subject: Re: [IBO] Big Batch...
>
> > Geoff -
> >
> > Thanks for the reply. I'm trying it now with the dsql
> > component.
> > However, all I've done is set the SQL property to use the
> > previoulsy
> > mentioned INSERT statement. It's executing one row at a time as
> > I write
> > this, no more quickly than the TIBOQuery did. Is there a better
> > approach
> > to doing this? Or should I continue to pursue doing this in
> > multiple
> > threads?
> >
> > Incidentally, I'm parsing the data into TStringLists prior to
> > inserting
> > into the database. Is there any in memory structure that I
> > could use to
> > just jam the stringlist's strings into the table all at once?
> > You know,
> > one big simultaneous transaction? Just a thought.
> >
> > TIA
> >
> > Dave
> >
> > Geoff Worboys wrote:
> > >
> > > Dont use TIBOQuery, its made for interactive use.
> > For the fastest
> > > possible inserts use TIB_DSQL. The BlobInserts
> > sample application
> > > that comes with IBO has an example of you to setup
> > this sort of thing.
> > >
> > > This sounds like some sort of problem with your
> > connection setup or
> > > possibly even a network problem. A more specific
> > error message would
> > > help.
> >
> > David Keith
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Please review the attached resume and skills narrative in consideration
for the position of , and contact me at your earliest convenience.
Thank you.
David Keith
[Non-text portions of this message have been removed]