Catastrophic Failure errors ( Delphi 4, SQL Server 7.0, Midas )

[Graham Hepper]

We have been experiencing severe problems with "Catastrophic Failures"
that appear to occur at random times while running our client
application. These errors seem to occur during data exchange with
the middle-tier ( dataset opens, or updates ).

Our current environment is Delphi4 ( Update 3), SQL Server 7.0 SP2,
and Windows NT 4.0/Windows 98.

The middle-tier is written so that it handles all insert, update, and
delete operations explictly, within the BeforeUpdateRecord event of
each TProvider.

Anyone have a clue what might be causing the "Catastrophic Failures"
we are getting?

[Xavier Pacheco (TeamB)]

Catastrophic Failures are not really as bad as they may seem. What
this means is that an exception is raised on the server and the client
does not know what the exception is. The way to debug this is to run
the server under Delphi, then when you run the client, the exception
breakpoint should come up when it occurs on the server. Hope this
helps.
-- x

Xavier Pacheco (TeamB)
Xapware Technologies Inc.
www.xapware.com
www.xapxone.com

------------------------------------------------
Sorry but TeamB cannot answer support
questions received via email.

[Roberto Icardi]

We have experienced many times this awful problem with D4. We have done a
serious investigation about that, but we have not determined exactly the
cause of the problem. It's an access violation in DBCLIENT.DLL, as you can
see following the instructions that Xavier gave you. We have seen that two
things make this problem more evident: the first is if you have more than
200 fields in you dataset (but not related with the length of the record),
and the second if you have poIncPropFields = True in your provider. But
randomly occurs in other circumstances, too. It's not related to transport
(we have caused the AV having query, provider and clientdataset all in the
same form, opening and closing the clientdataset for a random number of
times in a loop), neither to the database (we have tested with oracle and
paradox).
The only thing I can tell you is, based on my experience, to upgrade to
delphi5. We have done it 5 months ago, and we have had no more catastrophic
failures (but I'm crossing my fingers just now <g>)

[omar]

I have had those bad errors as soon as yesturday. With my system, the
problem was that every I used the
the type library tool to modify settings, and then when I click on the
refresh button, that adds extras to my
TLB unit those extra stuff where causing the problem for me, so as a fix, I
would go in and modify the TLB
file by hand to remove all extra stuff that the Type Library tool adds to
it, and that took care of the problem.
Also, make sure you un-register the server after modification are made to
it, so when you run it again it will register
with the new changes.

P.S. I am using Delphi 5.0

Good Luck.
Omar Bondogji

Graham Hepper <graham.hep...@NOSPAM.veco.com> wrote in message
news:396e25c4...@forums.borland.com...

[Alexander B. Deyto]

Would the UpdatePacks of Delphi 4.0 will address this problem?

[Roberto Icardi (Essedi)]

"Alexander B. Deyto" <alexnde...@hotmail.com> wrote in message
news:8l405l$ji...@bornews.borland.com...

> Would the UpdatePacks of Delphi 4.0 will address this problem?

No

[Pete Williams]

We were plaugued by these errors also. We are using D4 with DCOM and SQLServer 7,
distributed DB app.
Turns out the two faults were in our code - basically accessing memory we shouldn't. One
error was in our Delphi code, another in the driver we use for SQLServer access.
We don't use the BDE. Some super boffins here wrote a PowerBuilder Datawindow for Delphi
in Delphi and C++, and a Delphi component. Cool stuff.
Been OK for the past 6 months. For ages we though it was the Borland stuff, but it wasn't.
If you ask me, D4 is almost 100% (hope Borland gives their programmers lots of dosh).
You may want to look at Binh Ly's COM stuff too.

Pete.

[Joery F. Bermejo]

Yah right. I did an actual testing on this in our client and found these
things.

DataSource := GetDataBroker(sDatasetName).FDataSource;

The GetDataBroker function returns an Object which has a property
Datasource. I found out when you assigned
an object in this manner wherein the container or parent object of the
property FDataSource is nil this exception will appear. I have resolve this
problem by rewriting it to something like this.

DataBroker := GetDataBroker(sDatasetName);
if Assigned(DataBroker) then
DataSource := DataBroker.FDataSource
else raise Exception.Create('...');

So, I think to best way to solve this problem is to really test your
application server.

Roberto Icardi (Essedi) <roberto...@hotmail.com> wrote in message
news:8l45e4$np...@bornews.borland.com...