Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread DB Access Timeout Over WAN
Wed, Jan 10 2007 5:15 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image