I have a customer who is using my app both locally and over a WAN
(DBISAM 3.24 in shared file mode).  I know performance would be slower
over the WAN and have some remote users who can't even get the app
started.  However, when a local users travels to the remote location
with their laptop, they seem to get better performance than the other
remote users.  (I'm checking into converting to C/S to help with this.)

Are there networking settings or registry settings that I can have them
check to see what's different between the laptops carried to the remove
locations that seem to work and the workstations at the remote location
that don't?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon Turner wrote:

>
> Are there networking settings or registry settings that I can have
> them check to see what's different between the laptops carried to the
> remove locations that seem to work and the workstations at the remote
> location that don't?

File Sharing mode over a WAN is suicide, plain and simple.  The
difference in performance, between he laptops and workstations is
simply going to be the bandwidth available at that possible moment.

--
David Farrell-Garcia
Whidbey Island Software, LLC

David Farrell-Garcia wrote:
>
> File Sharing mode over a WAN is suicide, plain and simple.  The
> difference in performance, between he laptops and workstations is
> simply going to be the bandwidth available at that possible moment.

Thanks David.  I've already discussed this with the customer and
unfortunately other remote options that get around the bandwidth problem
(Terminal Server, Citrix Server) are not an option for them.  I'm
looking into modifying my code for C/S mode but struggling with certain
processes.  (Hence my post above about moving to the C/S environment.)

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon Turner wrote:
> Thanks David.  I've already discussed this with the customer and
> unfortunately other remote options that get around the bandwidth
> problem (Terminal Server, Citrix Server) are not an option for them.
> I'm looking into modifying my code for C/S mode but struggling with
> certain processes.  (Hence my post above about moving to the C/S
> environment.)

Hi Gorden,

Movig to C/S is not difficult.  Here are the main issues:

1. if they can connect to more then one database then you will need
some sort of connection dialog to pick the database.

2. If you are using Lookup tables you will need some structural
changes. Maybe cache them on the client at app start or temp tables
saved locally. There are a number of options here.

3. Using DbisamQuery instead of DbisamTable, if you have not done that
already, and optimized your sql to bring over only what you need.


4. Deploying the server. Pretty much a no brainer.

Other then that, your existing code should work.

--
David Farrell-Garcia
Whidbey Island Software, LLC

"David Farrell-Garcia" <davidF@NoStinkingSpamWhidbeyIslandSoftware.com>
wrote in message
news:26E52FF2-A3CC-49B6-82AE-6216A7AB7E8C@news.elevatesoft.com...
>
> Movig to C/S is not difficult.  Here are the main issues:
>
> 1. if they can connect to more then one database then you will need
> some sort of connection dialog to pick the database.
>

No different if you need to connect to different databases using file
sharing.

>
> 3. Using DbisamQuery instead of DbisamTable, if you have not done that
> already, and optimized your sql to bring over only what you need.
>

Why? Depends on the situation, and represents a lot of work and losing a lot
of the features found in tTable.

Robert

Gordon,

<< Are there networking settings or registry settings that I can have them
check to see what's different between the laptops carried to the remove
locations that seem to work and the workstations at the remote location that
don't? >>

I'm going to agree with David here - you're simply not going to get reliable
results using shared-file mode over a WAN.

--
Tim Young
Elevate Software
www.elevatesoft.com

David Farrell-Garcia wrote:
>
> Movig to C/S is not difficult.  Here are the main issues:
>
> 1. if they can connect to more then one database then you will need
> some sort of connection dialog to pick the database.
>
> 2. If you are using Lookup tables you will need some structural
> changes. Maybe cache them on the client at app start or temp tables
> saved locally. There are a number of options here.
>
> 3. Using DbisamQuery instead of DbisamTable, if you have not done that
> already, and optimized your sql to bring over only what you need.
>
>
> 4. Deploying the server. Pretty much a no brainer.
>
> Other then that, your existing code should work.

Hi David,

Changing from table to query components involves a major rewrite of the
program.  This is a commercial application so an update like this would
affect 800-900 current customers.  I need to stick with the current
components, so that I can produce an alternate version with compiler
directives so that I can continue to support my existing customers
without having to maintain two code bases.  A major rewrite of the
application is in the works for later this year, at which time I will be
moving to pure SQL based data access.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Robert wrote:
> No different if you need to connect to different databases using file
> sharing.

If you do it the same as you would with File Sharing you are not taking
advantage of the C/S features.

> Why? Depends on the situation, and represents a lot of work and
> losing a lot of the features found in tTable.

Does this really need a explaination?  You don't understand the
advantage of using SQL to query data on a server vs opening a
DbiasamTable?  You might get by with that in an app that never
generates much data but other then that it woudl be foolish.


--
David Farrell-Garcia
Whidbey Island Software, LLC

Gordon Turner wrote:

>> Hi David,
>
> Changing from table to query components involves a major rewrite of
> the program.

I understand.  I think we have all been there are one time or another.
If you are well versed in SQL it is actually much faster then you might
think to conver but I do understand your situation.


>  This is a commercial application so an update like this
> would affect 800-900 current customers.  

Mine affected about 3000.  We shipped it to only about 100 customers
who signed up to test, until we got all the bugs worked out.


>I need to stick with the
> current components, so that I can produce an alternate version with
> compiler directives so that I can continue to support my existing
> customers without having to maintain two code bases.  A major rewrite
> of the application is in the works for later this year, at which time
> I will be moving to pure SQL based data access.

Sounds like you have a plan then.  It should not be too difficult.  YOu
won't really get a lot of benefit from the C/S version until you start
using Queries, however.  Good luck!

--
David Farrell-Garcia
Whidbey Island Software, LLC

David Farrell-Garcia wrote:

>>Why? Depends on the situation, and represents a lot of work and
>>losing a lot of the features found in tTable.
>
>
> Does this really need a explaination?  You don't understand the
> advantage of using SQL to query data on a server vs opening a
> DbiasamTable?  You might get by with that in an app that never
> generates much data but other then that it woudl be foolish.
>
>
Sure SQL is the way to go. But won't a TDBISAMTable when using client
server, filter the data on the server? Like it does with ranges? Or does
it still pull the data down to the client to do the filtering?

TIA
Sam