OK, i confirm the parametized queries it's MUCH MUCH more fast than normal
query (up to 3x more fast!)

Was a little "hard" to understand the api to know how to use well the
parametized queries ...
i do component for that to make it more simple to use (delphi) and call
the query like
update(SQL, array of params);

now when i read this article

http://codicesoftware.blogspot.com/2008/04/fastest-way-to-insert-100k-registers.html

i thing a possibility to call update like in MySql

INSERT INTO testtable (iobjid, ifield0, ifield1) VALUES ({0}, {1}, {2}),
0, 300000, 50000, ({0}, {1}, {2}), 0, 300000, 50000 ...

can not be so bad as the problem of the parametized query is that they
need special components and it's could be good to run parametized query
from inside SQL text .....

On 1/26/2012 11:19 PM, Leyne, Sean wrote:
>
> > > Or is this what you're already doing, just that your example was
> > > simplified?
> > >
> > > HTH,
> > > Set
> > >
> >
> > yes, of course parametized queries will be more fast, but i don't
> think they
> > will change the ratio in the test (it's will simply be more fast for
> both
> > variantes)
>
> I would disagree!
>
> Your test was skewed and did not reflected the reality of
> prepare/parameterized statements! (the 2 scenarios are "apples and
> oranges")
>
> By using un-prepared statements, you reduced the disk IO load of your
> test and thus the overhead of Classic server page synchronization. In
> essence your test created "openings" to allow for multiple disk IO to
> occur.
>
> Using prepared statements will increase the speed of a single
> connection but also increase the synchronization overhead and disk
> contention. Thus reducing the benefit of parallel connections.
>
> Sean
>
>


[Non-text portions of this message have been removed]