At 08:35 PM 27-03-02 -0800, Joe Martinez wrote:

>Ok, an update...

I wrote

> > There is another dimension that hasn't been mentioned so far: the BDE
> > version. The InterBase driver in Delphi 4 and 5 supports InterBase
> > 5.x. The one that shipped with Delphi 4 had known bugs. The one with D5
> > had known bugs. Neither was ever certified for use with ODS-10 databases
> > (IB 6.x, Firebird...) Even the BDE 5.2 IB 6.x driver that shipped with
> > Delphi 6 has known bugs (different ones!)
>
>The BDE version is 4.0, which shipped with BCB4. Is this a problem?

Are you CERTAIN that BCB4 shipped with BDE 4.0? That is pretty
incredible. The current BDE at the time BCB4 went out (last qtr 1999?) was
either BDE v.5.1 or 5.1.1. If I recall correctly, the 5.1.1 fix followed
quite swiftly upon the first major update of Delphi 4 and would have been
available when BCB 4 came out. In any case, BDE went up to 5.2 with the IB
6.x driver...

> > I don't think it is very sensible of you to have deployed an early beta of
> > Firebird into production. You should upgrade your customers to Firebird
> > 1.0 without delay, to avoid a large number of known bugs in that old
> > beta. The obvious architectural flaws (BDE and TTables) you plan to
> > address...but there is a good chance that your immediate problem will show
> > up as an exception with Firebird 1.0.
> >
>
>Well, here's the thing with that. When Interbase 6 went out of beta, I
>modified the next release of my app to work with it. I made deals and took
>orders, based on the fact that Interbase 6 was free. Everything was going
>perfect in my development and testing. Just before shipping, I read that FB
>0.9.4 was available, and that it had fixed some bugs that were present in IB6.
>It seemed like a better choice to deploy the beta FB than the less-stable
>non-beta IB6. I don't think that that was the wrong choice. Besides, the
>IBPhoenix web site touts FB 0.9.4 as "A build that has been successfully run
>through the complete TCS test suite and has proved to be stable in operational
>environments.".

Sure: but much water and many dead bugs have crossed under the bridge
since then!

Going back to your original "problem". Can you provide more info about it,
what you are seeing that makes you think separate transactions are
interfering with one another's updates?

As (I hope) you can tell from the complicated cross-traffic on this thread,
it's not seen as inconsistent if you observe that first one then another
transaction updates the "same" row in a table. If there were no lock
conflicts when the second update was posted, the second user wouldn't be
stopped from posting an update on an already-committed row...there would be
a conflict if the second transaction were Read Committed +
Record_Version; but the BDE transaction is Concurrency (Snapshot), AFAIK.

cheers,
Helen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________