I've got a program written in Delphi 5 utilizing DBISAM 3.03 Client/Server (Server is the
supplied 5 connection version).

The Server is running on a dedicated machine, listening on port 12001 (regular) and 12002
(Admin). My users running on the LAN have no problems connecting, accessing the databases,
etc.

Remotes access the server via a VPN/public IP set up on a router. I did not set this up
but I'm told the VPN basically routes connections to the public IP to the server machine's
appropriate ports (specifically, ports 12001-12002).

Up until about a week ago the remotes were connecting fine. Then we started to have
problems; i.e. they would intermittently get the 11280 connection cannot be established
message. Intermittently means it might work throughout one day, then not the next. Might
work in the morning, not in the afternoon. When they cannot access the server I have the
users see if they can ping the private IP of the server machine (the one the DBISAM server
is running on) and they cannot.

The guy who set up the router/VPN should know what he's doing, but so do I (I think).
Nonetheless, I'm asking if it is possible that connection dropping or other programmatic
events could possibly cause this kind of weird behavior. I've asked about firewalls (which
is what it seems like) and have been assured there are no firewalls (even the Windows
firewall) running on the server or the client machines. The problem seems never to occur
in the middle of a program session; rather, it rears its ugly head after the remote user
has closed my client and then tried (after a few minutes or a few hours) to reattach to
the DBISAM server.

Any thoughts would be appreciated.

=NLK=

N.L.,

<< Nonetheless, I'm asking if it is possible that connection dropping or
other programmatic events could possibly cause this kind of weird behavior.
I've asked about firewalls (which is what it seems like) and have been
assured there are no firewalls (even the Windows firewall) running on the
server or the client machines. The problem seems never to occur in the
middle of a program session; rather, it rears its ugly head after the remote
user has closed my client and then tried (after a few minutes or a few
hours) to reattach to the DBISAM server. >>

Is the version you're using 3.03, or 3.30 ?  If you're using 3.03, then you
should probably upgrade to 3.30 because the earlier versions of 3.x were a
little buggy with respect to the C/S functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

The Server version is 3.03; although I have 3.3, the app is using Ver 3.03 tables. Can I
use the 3.3 Server with the 3.03 tables?

Norman

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

N.L.,

<< Nonetheless, I'm asking if it is possible that connection dropping or
other programmatic events could possibly cause this kind of weird behavior.
I've asked about firewalls (which is what it seems like) and have been
assured there are no firewalls (even the Windows firewall) running on the
server or the client machines. The problem seems never to occur in the
middle of a program session; rather, it rears its ugly head after the remote
user has closed my client and then tried (after a few minutes or a few
hours) to reattach to the DBISAM server. >>

Is the version you're using 3.03, or 3.30 ?  If you're using 3.03, then you
should probably upgrade to 3.30 because the earlier versions of 3.x were a
little buggy with respect to the C/S functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Yes

Norman L. Kleinberg wrote:
> The Server version is 3.03; although I have 3.3, the app is using Ver 3.03 tables. Can I
> use the 3.3 Server with the 3.03 tables?

Norman,

<< The Server version is 3.03; although I have 3.3, the app is using Ver
3.03 tables. Can I use the 3.3 Server with the 3.03 tables? >>

As Jason indicated - yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

OK. Thanks both. Right now things have calmed down after the network guy made some
modifications to the router (won't tell me what he did). But I'll keep the 3.3 server in
reserve and also try to remember this for the future. Frankly, though, I hope I don't have
to: I'd prefer to update to the latest version if I can just get up the energy to tackle
the InMemory property.

Norman

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Norman,

<< The Server version is 3.03; although I have 3.3, the app is using Ver
3.03 tables. Can I use the 3.3 Server with the 3.03 tables? >>

As Jason indicated - yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Norman,

When creating VPN tunnels most routers/firewalls are programmed be default
only to stay up/active while there is data traffic.  When there is no
traffic over the tunnel after a few minutes the vpn will close to preserve
bandwith.  This could explain why it work most of the time and then problems
occur.

What you or the router guy have to do is to force the tunnel to always stay
active, most router can do this.  This is most likely what the network guy
did.

So it was his fault all the time, anyway you knew taht!

Rijk


"Norman L. Kleinberg" <nlk11021@yahoo.com> wrote in message
news:379C6805-5610-40D9-B92F-FB2C50246442@news.elevatesoft.com...
> OK. Thanks both. Right now things have calmed down after the network guy
> made some
> modifications to the router (won't tell me what he did). But I'll keep the
> 3.3 server in
> reserve and also try to remember this for the future. Frankly, though, I
> hope I don't have
> to: I'd prefer to update to the latest version if I can just get up the
> energy to tackle
> the InMemory property.
>
> Norman
>
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
>
> Norman,
>
> << The Server version is 3.03; although I have 3.3, the app is using Ver
> 3.03 tables. Can I use the 3.3 Server with the 3.03 tables? >>
>
> As Jason indicated - yes.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Rijk:

Hey, your guess is as good as (probably better than) mine, but then how would one ever
initiate a
connection? It wasn't that the client could NEVER connect without help. In bursts he could
log on, log off,
etc. with time lapses from a few minutes to a few hours. At other times, as I mentioned,
we couldn't
even ping the IP.

It's really like a lot of things: in retrospect all will be clear. It's like some papers I
write: I kill myself
to figure things out and the referee tells me "it's obvious". Yea, it's obvious, after you
rip your guts
out setting it all up. I suspected it was the VPN setup but I've been around long
enough to know
that anything is possible: as long as it's working now I'm OK, although I WOULD like to
know what
happened, if only for future reference.

Thanks for taking the time to chime in. I got a chuckle from your post.


Norman

"Rijk van der Merwe" <rvdm@vooma.co.uk> wrote:

Norman,

When creating VPN tunnels most routers/firewalls are programmed be default
only to stay up/active while there is data traffic.  When there is no
traffic over the tunnel after a few minutes the vpn will close to preserve
bandwith.  This could explain why it work most of the time and then problems
occur.

What you or the router guy have to do is to force the tunnel to always stay
active, most router can do this.  This is most likely what the network guy
did.

So it was his fault all the time, anyway you knew taht!

Rijk


-snip-