Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
DB Access Timeout Over WAN |
Wed, Jan 10 2007 5:15 PM | Permanent Link |
Gordon Turner | My program uses D7 and DBISAM 3.24. I have a customer who is connecting
from the application on the workstation to the data files (non c/s) over a dedicated VPN and the application is not responding when it attempts to check the field size in one of the tables. I'm using the following code: if TableName = 'Employee' then begin { check to make sure the Name fields are the right size } with RestructureFieldDefs do begin Update; try FieldDef := Find('LastName'); if FieldDef.Size <> 30 then begin FieldDef.Size := 30; FieldDef := Find('FirstName'); FieldDef.Size := 20; RestructureIndexDefs.Update; RestructureTable(0,0,1,0,False,'','Employee Information',512, -1, '',nil,'','',True); end; except on E: EDBISAMEngineError do begin TableToCreate.Free; raise; end; on E: EDatabaseError do begin ShowMessage('Failed to fix Employee name fields.'); end; end; end; {further checks here} end; As best I can tell, the application is freezing on the Update statement. This process works fine on LAN installations, and even on the customer's LAN, so I'm not sure why it would time out on the WAN/VPN. This check is the first performed as the application starts up. The user can update a text file in the folder without a problem so I know it's not a rights issue. Workstation - WinXP Pro SP2 Server - Win 2000 SP4 - share is part of an Active Directory. Any ideas what else to check to see why the app times out on that statement? (No exception is raised.) -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Wed, Jan 10 2007 5:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< As best I can tell, the application is freezing on the Update statement. This process works fine on LAN installations, and even on the customer's LAN, so I'm not sure why it would time out on the WAN/VPN. This check is the first performed as the application starts up. The user can update a text file in the folder without a problem so I know it's not a rights issue. >> Can your application perform other tasks just fine across the VPN ? Frankly, such a setup is going to be extremely slow to begin with, so you may just be running into something that isn't going to be feasible given the speed of the VPN. If you can swing it, I would suggest switching to using the 5-connection database server and a remote session for the VPN connection instead of a direct connection. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 11 2007 8:55 AM | Permanent Link |
Gordon Turner | Tim Young [Elevate Software] wrote:
> > Can your application perform other tasks just fine across the VPN ? > Frankly, such a setup is going to be extremely slow to begin with, so you > may just be running into something that isn't going to be feasible given the > speed of the VPN. If you can swing it, I would suggest switching to using > the 5-connection database server and a remote session for the VPN connection > instead of a direct connection. One of the first tasks the application performs is to connect to the database (although it does display the splash screen). I have backup and restore features tied to the physical files (zip and unzip of the dat, idx, & blb files). Is there a way in version 3 to get the physical location of the data files from the server? (I'm assuming the other table based access functions - Next, Previous, Locate, FindKey, etc. all work with the C/S version.) -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Thu, Jan 11 2007 7:03 PM | Permanent Link |
"David Farrell-Garcia" | Gordon Turner wrote:
> One of the first tasks the application performs is to connect to the > database (although it does display the splash screen). YOur database engine, as I am sure you are aware, in your setup, resides on your client. YOur server is simply a filestore. The fact that it works well on the LAN an not on the WAN most likely indicates that the bottleneck is your bandwidth. This is not suprising in a non-client server database system. I stongly suggest that you move to C/S or to a middleware library. Moving to Dbisam C/S would be a no-brainer upgrade for your application and increase performance on your LAN while making your WAN connection acceptable. -- David Farrell-Garcia Whidbey Island Software, LLC |
Thu, Jan 11 2007 7:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< I have backup and restore features tied to the physical files (zip and unzip of the dat, idx, & blb files). Is there a way in version 3 to get the physical location of the data files from the server? >> Yes, but the physical path returned will be in relation to the database server and not useful to the client. However, you could very easily move this functionality into a server-side procedure in the database server so that it can execute from the server instead. << (I'm assuming the other table based access functions - Next, Previous, Locate, FindKey, etc. all work with the C/S version.) >> Yes. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 12 2007 12:18 PM | Permanent Link |
Gordon Turner | David Farrell-Garcia wrote:
> > YOur database engine, as I am sure you are aware, in your setup, > resides on your client. YOur server is simply a filestore. The fact > that it works well on the LAN an not on the WAN most likely indicates > that the bottleneck is your bandwidth. This is not suprising in a > non-client server database system. That's what I thought as well, although I'm not familiar enough with VPN's to know if there are also configuration issues that might block access to the data files across the WAN. > I stongly suggest that you move to > C/S or to a middleware library. Moving to Dbisam C/S would be a > no-brainer upgrade for your application and increase performance on > your LAN while making your WAN connection acceptable. > I agree that it would be a good move. However, this is one of our main products and supporting the installation and configuration of the server software is a major hurtle for us. I need for it to be as transparent as possible for the user/customer. Many of our customers are not very computer knowledgeable, and would not know about IP addresses, ports, etc., or any restrictions on those in their network. That's the advantage of the shared file approach. -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Fri, Jan 12 2007 12:40 PM | Permanent Link |
Gordon Turner | Tim Young [Elevate Software] wrote:
> > Yes, but the physical path returned will be in relation to the database > server and not useful to the client. However, you could very easily move > this functionality into a server-side procedure in the database server so > that it can execute from the server instead. > Thanks Tim. We are in the process of revising our program architecture and will look at that as a c/s option. I'm guessing this will be even easier in the ElevateDB vesion (which we expect to be using). -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Fri, Jan 12 2007 6:38 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< Thanks Tim. We are in the process of revising our program architecture and will look at that as a c/s option. I'm guessing this will be even easier in the ElevateDB vesion (which we expect to be using). >> Yes, local <---> C/S in EDB is even easier since even the user security, database creation, stored procedures, etc. are all the same with both. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, March 27, 2024 at 05:29 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |