<Snip from original message>
"
Think of an user editing a record, posting it, not
ending the transaction, and changing it again.
"

If you are relying on the user for transaction control (starting and
commiting transaction), via the client application, you're setting yourself
up for some nasty, nasty times, at least in a multi-user environment with
either IB or FB..


Best regards,
Fred Wilson
SE, Bell & Howell
fred.wilson@...


-----Original Message-----
From: Adrian Roman [mailto:aroman@...]
Sent: Sunday, July 14, 2002 12:48 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Re: FB slow

> I don't want to waste a lot of time in conjecturing this, since it's not
> something that would (should) be done to production data and wouldn't be a
> requirement for any transaction-capable DBMS. Why is it an important test
> for you?

Because if it's slow in a situation like this one, I could expect to be slow
for something that's a requiement for a DBMS.
And I know that' sometimes it happens to modifiy the same record twice in a
single transaction. Think of an user editing a record, posting it, not
ending the transaction, and changing it again.

> How would the engine know that? It still has to locate each delta record
> by walking both the cache and the original versions. On your first pass,
> it attacks the data in natural order; on subsequent passes it has to
> compare two sets of data, each with its own natural order. When a query is
> slow, the time cost is a matter of navigation, not the time it takes to
> alter data.

It does not need to locate each delta record, since it's changing data
changed in current transaction, so it's changing only the current record.


Adrian Roman



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/