Help, Deep Trouble with BDE 5.1 (ORACLE 8.4)

Mike Evans

unread,

Sep 22, 1999, 3:00:00 AM9/22/99

to

The Facts:
1. I just started using bde5.1
2. I have always used shared autocommit
3. I just switched to Oracle 8.04 on novell

The Problems:
1. My delphi apps cannot see updates made by other delphi apps until
I end the session.
2. If I try to update a record updated in the other session/computer, my
Delphi app hangs. (SQL PLUS also hangs on the update statement)

More Facts:
MS Access (Linked tables) via Oracle ODBC *CAN* see the autocommited
updates.
SQL Plus cannot see the "autocommmited" updates

WHats up?

Mike Evans
p...@mcs.net

Brian Cohen

unread,

Sep 24, 1999, 3:00:00 AM9/24/99

to

Is this happening on TTable, TQuery or both?

We don't seem to be having this problem, though we only use TQuery and
do a lot of pass-through begin/commit logic ourselves.

We do set the BDE at SHARED AUTOCOMMIT and do have several
auto-transactions. I guess we should test these again!

Brian Schuth

unread,

Sep 24, 1999, 3:00:00 AM9/24/99

to

I just ran into this myself, on Oracle 8.0.5. I played around with just
about everything I could, and then spent a day changing over to explicit
transaction control (StartTransaction and Commit). My good news was that we
have a separate database layer and rather extended inheritance hierarchy
which meant the task wasn't overwhelming. The bad news is that so far as I
can tell autocommits are broken in BDE/Oracle. I had problems with both
5.01 and 5.10, and was not able to fall back to the 4 series. I've not
worked with Oracle 7.*; did auto-commits work correctly there?

BTW, this was all with TTable. We use TQuerys, but we use TTables for
updating; the queries aren't live. There is still a possibility this is
TTable specific.

> > 1. My delphi apps cannot see updates made by other delphi apps until

*Nothing* can see the updates. They are not being committed until the
session ends (and if you crash in the middle of your session, EVERYTHING is
lost).

Sorry...

bjs

Mike Evans

unread,

Sep 27, 1999, 3:00:00 AM9/27/99

to

I use TQueries
AutoCommits Work Correctly with Oracle 7 and 8
BDE5.1 is the problem

I think I will have to change to explicit auto commits too. I day will just
get me started though...

Thanks

Mike

Brian Schuth wrote in message <7sg350$69...@forums.borland.com>...

Jeff Overcash (TeamB)

unread,

Sep 27, 1999, 3:00:00 AM9/27/99

to

This is a known problem and Borland is trying to get it fixed. IIRC the problem
can be gotten around by not mixing explicate and implicate transactions in your
application. I wish I could find that reference again, but I believe that it
you always use autocommit you will be fine or if you always start transactions
and commit them you are ok, it is only when you mix the two that the problem
appears. I could be off on that though.

Mike Evans wrote:
>
> I use TQueries
> AutoCommits Work Correctly with Oracle 7 and 8
> BDE5.1 is the problem
>
> I think I will have to change to explicit auto commits too. I day will just
> get me started though...
>
> Thanks
>
> Mike
>

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
virgins giggle with their bodies glowing bright. Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
(new classic Genesis) Carpet Crawlers 1999
--

Jeff Overcash (TeamB)

unread,

Sep 27, 1999, 3:00:00 AM9/27/99

to

Yes, I know that one too, and I do think they are related. Borland is trying to
get this and a couple of other critical bugs fixed and an updated BDE out.
Unfortunately past that I really can't say much. Full recursive testing of the
BDE tends to take 2-3 weeks so patches tend to address as many bugs as possible.

Mike Evans wrote:
>
> Thanks Jeff
>
> Do you know about the locking problem too? It seems to go along with the
> autocommit.
>
> Session A posts an update statement on row #1
>
> Session B attempt to post an update to the same row (#1)
> Session B Hangs
>
> Session A continues to process add and update etc.
> 1 or 2 minutes go by
> Session A ends
>
> Session B continues

Mike Evans

unread,

Sep 27, 1999, 3:00:00 AM9/27/99

to

Thanks Jeff

Do you know about the locking problem too? It seems to go along with the
autocommit.

Session A posts an update statement on row #1

Session B attempt to post an update to the same row (#1)
Session B Hangs

Session A continues to process add and update etc.
1 or 2 minutes go by
Session A ends

Session B continues

Jeff Overcash (TeamB) wrote in message <37EFAF2A...@onramp.net>...

>This is a known problem and Borland is trying to get it fixed. IIRC the
problem
>can be gotten around by not mixing explicate and implicate transactions in
your
>application. I wish I could find that reference again, but I believe that
it
>you always use autocommit you will be fine or if you always start
transactions
>and commit them you are ok, it is only when you mix the two that the
problem
>appears. I could be off on that though.
>
>Mike Evans wrote:
>>
>> I use TQueries
>> AutoCommits Work Correctly with Oracle 7 and 8
>> BDE5.1 is the problem
>>
>> I think I will have to change to explicit auto commits too. I day will
just
>> get me started though...
>>
>> Thanks
>>
>> Mike
>>
>
>