Hi Everybody

I'm having a problem handling of communication failour to my paradox tables.

My database is places on a network share. Either a mapped drived or a UNC
path.

The access to the database is working correct.

Ok, here's the problem.

If a network problem arises and the connection to the database is lost,
then, if I try to close my application, it'll take about 1 minute for my
application to terminate, there is no AV or other errors, just some timeout
which keeps my application "hanging".

Does anyone have any solution for that?

regards
Henrik

Fix the network problem.
--
Finn Tolderlund

"Henrik Nedergaard" <itserv...@mail.dk> skrev i en meddelelse
news:3cc877c0$1_1@dnews...

Jezzes Finn what kind of an answer is that?

Henrik

A good answer IMHO.
The problem is the network.
Fix the problem.
--
Finn Tolderlund

"Henrik Nedergaard" <itserv...@mail.dk> skrev i en meddelelse
news:3cc916c5$1_1@dnews...

I think it's a quite foolish answer and it doesn't answer the question (at
least the one I intended to get an answer for)

In the first place, yes, but when my application appears to be hung for
appox. a minute then the problem is mine if you ask a customer (have you
ever tried that?)

sure thing, but how.

henrik

Hi Henrik,

The "hanging" you are talking about may acutally be caused by Windows
itself. In other words say you are in windows explorer displaying the
contents of a mapped network drive and then you lose the network
connection (for example I switch off my hub). Clicking on any folder
or file for that location (and sometimes just choosing File - Exit
from the menu) causes Explorer to temporarily hang. This is because
windows is trying to re-establish the connection.

So now looking at your application, obviously when the network
connection disappears and then you reference the disconnected network
location (even to close a file/table) - there will most likely be a
delay.

How to solve this problem ?

Well you really need to try and understand why the network connection
keeps disappearing because it must be resolved. If the network
connection disappears whilst a write operation to a paradox table is
in progress, it is highly likely that the table will be corrupted. At
best you will get an index out of date error.

So in truth a flakely network connection is pretty useless.
Hope this makes sense to you
Leslie.

news:3cc877c0$1_1@dnews...

"Henrik Nedergaard" <itserv...@mail.dk> skrev i en meddelelse
news:3cc94470_1@dnews...

Perhaps not the answer you wanted.
You have to realize that you can't solve a problem by trying to fix
something that isn't broken.

I deal with customers almost every day.
In my experience when you accept a problem which really isn't your problem,
the problem just grows bigger and that will cause problems with the relation
between you and your customer.
If you convince your customer that it is your problem they will get angry
with you when they discover that you can't fix the problem nomatter what you
do.
The only way is to tell your customer what the problem is and what *they*
should do to fix it.
It's their problem, not yours.
Do yourself and your customer a faviour and say that.
The problem won't go away by putting a bandaid on your software.
The problem will just grow bigger.

Since it's a hardware problem ask your customer to have some technicians
look at it.
--
Finn Tolderlund

I see your point there since BDE is using files that must be the reason for
the "hung up app".

I do understand that a unreliable network is bad, no problem, all I want is
that my application terminates when the user clicks OK on my errordialog in
stead of terminating to app stays on the windows processbar (and
taskmanager) for about one minute. I have traced my app. and all threads,
forms aso. terminates perfect except from the datamodule when it closes the
session of the "lost" database.
I though of doing some sucide actions but that would probably create even
more problems.

I guess what i have to understand here is that I cannot make my app. better
than windows ;o)

Thanks
Henrik

No, there is no solution for that other than Finn's. The timeout is
controlled by the network software. There may be some way to change that for
all applications but that is not a solution. If you shorten it you will just
get false timeouts if the network is busy. The larger problem is that if the
network connection is going down and you are using a file server database,
such as Paradox, sooner or later you will get corrupt tables or indices. If
you were using a database server with transaction support you would not have
to worry about corrupting the database or leaving the data in an
inconsistent state. In that case an unstable network would not be as big a
problem. However, in your case Finn is right; you need to fix the problem.

--
Bill
(TeamB cannot answer questions received via email)