Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
Intermittent Server VPN Problem |
Thu, Sep 21 2006 1:40 PM | Permanent Link |
N.L. Kleinberg | 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= |
Thu, Sep 21 2006 4:13 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Sep 22 2006 10:47 AM | Permanent Link |
Norman L. Kleinberg | 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 |
Fri, Sep 22 2006 1:01 PM | Permanent Link |
Jason Lee | 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? |
Fri, Sep 22 2006 2:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Sep 22 2006 2:55 PM | Permanent Link |
Norman L. Kleinberg | 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 |
Sat, Sep 23 2006 6:18 AM | Permanent Link |
"Rijk van der Merwe" | 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 > > |
Sat, Sep 23 2006 10:24 AM | Permanent Link |
Norman L. Kleinberg | 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- |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |