Subject | Re: [IBO] yikes! Help! |
---|---|
Author | Tom Deprez |
Post date | 2001-12-06T02:03:59Z |
Hi Jason,
No, CachedUpdates was only an improvement upon something at the time which
was handled even worse that in it was.
CachedUpdates actually adds additional labor and gyrations to the entire
process. Direct updates are always more efficient if properly done, which
the BDE didn't necessarily do.
Thanks for the above explanation.
The thing that CachedUpdates can do to make things feel better to the user
is it allows them to not hit the network with their changes until the very
end. You are metering the whole process from start to finish and cached
updates are not going to improve performance in that scenario.
I must say, these are some lengthy timings, what are you doing? IOW, details
please.
I'm moving an access table of 3240 records to an Interbase table. For every access record I've to look if it already exists in the interbase table (using Locate), if it does, then I've to update the interbase record, if it doesn't exist, I've to add the record to the interbase table.
Is this detailed enough? Is there a better way?
PS. You are highly advised to make sure you are on a version of IBO later
than 4.2 Fl. I was recently able to root out a problem in cached updates I
thought worthy of putting in red in the release notes. I highly recommend
you get the release I just put out there, IBO 4.2 Fn. It is a culmination of
a policy of "bug fixing only" for the past few months and I have rooted out
dozens of bugs now, some of which have been significant. The release notes
has all the gory details.
Mmm, I should update the components, I'm using 4.2Fe. I'll let you know what improvements it made. But first I've to sleep. It's 3 o'clock in the morning here.
Tom.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
No, CachedUpdates was only an improvement upon something at the time which
was handled even worse that in it was.
CachedUpdates actually adds additional labor and gyrations to the entire
process. Direct updates are always more efficient if properly done, which
the BDE didn't necessarily do.
Thanks for the above explanation.
The thing that CachedUpdates can do to make things feel better to the user
is it allows them to not hit the network with their changes until the very
end. You are metering the whole process from start to finish and cached
updates are not going to improve performance in that scenario.
I must say, these are some lengthy timings, what are you doing? IOW, details
please.
I'm moving an access table of 3240 records to an Interbase table. For every access record I've to look if it already exists in the interbase table (using Locate), if it does, then I've to update the interbase record, if it doesn't exist, I've to add the record to the interbase table.
Is this detailed enough? Is there a better way?
PS. You are highly advised to make sure you are on a version of IBO later
than 4.2 Fl. I was recently able to root out a problem in cached updates I
thought worthy of putting in red in the release notes. I highly recommend
you get the release I just put out there, IBO 4.2 Fn. It is a culmination of
a policy of "bug fixing only" for the past few months and I have rooted out
dozens of bugs now, some of which have been significant. The release notes
has all the gory details.
Mmm, I should update the components, I'm using 4.2Fe. I'll let you know what improvements it made. But first I've to sleep. It's 3 o'clock in the morning here.
Tom.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Tom Deprez" <zifnabbe@...>
To: <ibobjects@yahoogroups.com>
Sent: Wednesday, December 05, 2001 4:55 PM
Subject: [IBO] yikes! Help!
> Hi,
>
> I've a problem here:
>
> I try to test several setups for updating a Table/Query
>
> I've used a TIBOTable and with my test dataset it took 32 sec to
add/update
> data to a table in interbase.
> I've used a TIBOQuery with CachedUpdates = FALSE and this took also 32
sec.
> Now, I tried the same setup of the TIBOQuery, but with CachedUpdates =
TRUE,
> this takes 4 min and 11 sec!
> Using the TIBOQuery with a view on the same table and cachedupdates =
FALSE
> (and using editSQL and insertSQL), it takes 39 sec.
>
> I tought CachedUpdates = TRUE would improve speed since it will first
cache
> the updates/inserts and then send it later to the server...
>
> Can somebody explain me this? Is this a normal behavior?
>
> Thanks in advance,
> Tom.
Yahoo! Groups Sponsor
ADVERTISEMENT
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]