Hello,

I'm using a C/S setup where I install the (Delphi) app at the client (on a shared network drive), test it out and it works, then at some later point, will fail to connect to the database.

That is, I start it. It works. I exit. The users start it up, and it works for them. They exit. A few hours or days later, they go to start it up and it fails to connect.

Initially this would happen because I had the table components active on the forms, but I closed them all and use a routine to open them after the database connection occurs. And now I've got several occurrences where I know the app works, it doesn't change, but then suddenly it won't connect.

It's so unreliable that I switched the app to being local, but that results in the dreaded #11013 error. I'm trying to work around that (Trend Micro A/V, but I've had that problem on my local machine and I don't run anything. I can't remember how I fixed it though, either.

But I'd rather just have it be a proper C/S app;  I'm just at a loss on how to proceed. I don't see how it can be the app but I can't figure out where to direct the network people to investigate.

Anyone have any thoughts?

Blake,

First of all, exclude the *database* directory and the folders used to store *temporary tables* (TDBISAMSession.PrivateDir) from Anti-Virus scanning. I believe your Anti-Virus has some way to exclude directories from scanning. Also, check how you are opening tables, are some of them being opened exclusively (TDBISAMTable.Exclusive)?

About changing it to be a C/S application, thats not too hard.
Its only a few easy steps to turn your application into a C/S application. You just have to set TDBISAMSession.SessionType to stRemote, TDBISAMSession.RemoteAdress to the IP of the server, also RemoteUser and RemotePassword to the default user/passwords and you are all set.
Of course there are further consideration on optimizing performance and security in a C/S environment, but as a starting point, this is it.
Let us know if you need further assistance.

--
Fernando Dias
[Team Elevate]

Fernando,

Well, I maybe wasn't clear but I changed this to a C/S app early on, but I keep getting connection problems. (And it is really easy to do.)

In desperation, I switched it BACK to a standalone and now I've got these access issues. I'm going to try to fix those but I think it'd be best if it were a C/S app.

As it stands my app will run as a standalone, local server or remote server based on how it's started. Could that be a source of problems?

Just to clarify--the issue I'd REALLY like to solve is this one where my app connects to the remote server sometimes but then not others. I think it's something wonky with the network since it only happens at the client site, never on my test network.

Any hints I can get to solving this would be greatly appreciated!

How do you connect to the dbsrvr - host name or the IP ?

What i would start with is to try to narrow it down . Next time they
have problems connecting :

1. can they ping the host with the dbsrvr ?

2. if yes then can they try connect using telnet ? (e.g. "telnet
<ip/host> 12005")

If both of those work then IP layer is all OK and issue is in your app.

If either of those fails then network connectivity is an issue (or AV on
client or server side)

Raul



On 7/27/2012 11:51 PM, Blake wrote:
> Hello,
>
> I'm using a C/S setup where I install the (Delphi) app at the client (on a shared network drive), test it out and it works, then at some later point, will fail to connect to the database.
>
> That is, I start it. It works. I exit. The users start it up, and it works for them. They exit. A few hours or days later, they go to start it up and it fails to connect.
>
> Initially this would happen because I had the table components active on the forms, but I closed them all and use a routine to open them after the database connection occurs. And now I've got several occurrences where I know the app works, it doesn't change, but then suddenly it won't connect.
>
> It's so unreliable that I switched the app to being local, but that results in the dreaded #11013 error. I'm trying to work around that (Trend Micro A/V, but I've had that problem on my local machine and I don't run anything. I can't remember how I fixed it though, either.
>
> But I'd rather just have it be a proper C/S app;  I'm just at a loss on how to proceed. I don't see how it can be the app but I can't figure out where to direct the network people to investigate.
>
> Anyone have any thoughts?
>

Blake,

You have been clear, I'ts my fault, I haven't read it properly, sorry.
Anyway, what I said about the anti-virus is still valid, no matter you are using C/S or File Sharing.
As Raul already said, if its not a network issue, it still can be the AV playing.
Does their AV do any kind of network traffic filtering, port blocking, that kind of stuff ?

Also, what DBISAM version are you using?

--
Fernando Dias
[Team Elevate]

Blake,

<< As it stands my app will run as a standalone, local server or remote server based on how it's started. Could that be a source of problems? >>

No, I don't think so, I have a few applications doing exactly the same, starting a remote or local session depending on an a few INI file settings or user's options at login.

--
Fernando Dias
[Team Elevate]

Wait, so the anti-virus issue could be causing the "cannot connect" issue in C/S mode?

I guess that'd make sense but it had not occurred to me. Would there be any log info on that were it to happen?

Thanks for your help.

They have been able to ping the server. I haven't tried telnet, but I will.

Yes - I've had that problem before and in case of one customer turning
off the real-time scanning had no effect on the network scanning
(network protection had to be disabled separately).

However, since you're saying it's intermittent (works now and then not
few hours later) it might not be the cause - i would except AV to block
always - so make sure you check all other aspects as well.

Only place it would be logged is in AntiVirus log - assuming they log
network layer blocking and scanning.

Raul


On 7/28/2012 7:50 PM, Blake wrote:
> Wait, so the anti-virus issue could be causing the "cannot connect" issue in C/S mode?