Just bought V4 (always late, me) and converted a few apps, so far with few
if any problems. a few questions follow:

1. It seems that C/S is consistently faster in V4 than fileserver (was not
the case in V3). Is that everybody's experience?

2. I'm tring to determine a good backup setup (right now I copyfile each DAT
and IDX file) using the new backup and restore methods. Questions are:

2.1 In C/S, can I use a Database as backup destination? It seems silly to
have to code a path in C/S mode, one should set all that up using the
database administrator.
2.2 Can I use the same backup/restore methods when running C/S or
fileserver?

3. Is it necessary to do something special to keep the server connection
open when the terminal is inactive? If so, what?

Robert

> Just bought V4 (always late, me) and converted a few apps, so far with few
> if any problems. a few questions follow:

Congrats. I love V4!

> 1. It seems that C/S is consistently faster in V4 than fileserver (was not
> the case in V3). Is that everybody's experience?

I have that experience also. C/S doesn't have the locking "slowdown"
that fileserver setups have with multiple users.

When you code your application to "think" Client/Server, it even becomes
faster. For example, navigating datasets (while...not...eof...next) in
C/S mode is faster when Query.RemoteReadSize is set.


> 2. I'm tring to determine a good backup setup (right now I copyfile each DAT
> and IDX file) using the new backup and restore methods. Questions are:
>
> 2.1 In C/S, can I use a Database as backup destination? It seems silly to
> have to code a path in C/S mode, one should set all that up using the
> database administrator.

No, although that would be a good feature to have.

> 2.2 Can I use the same backup/restore methods when running C/S or
> fileserver?

Yes.

> 3. Is it necessary to do something special to keep the server connection
> open when the terminal is inactive? If so, what?

You can use the "Ping" feature and set it to ping the server every 60
seconds, for example. Ping is a feature of the TDBISAMSession component.

"Jason Lee" <computerguy@wavecable.com> wrote in message
news:067A37E1-638A-4F9C-A2F9-3A195D293EE6@news.elevatesoft.com...
> C/S mode is faster when Query.RemoteReadSize is set.
>

Thanks for the feedback. Are the defaults documented soemwhere?

Robert

The default for RemoteReadSize is 1. Only one record will be fetched at
a time. This means the client must communicate with the server if you
want the next record fetched. If you set RemoteReadSize to 20, however,
then 20 records are fetched in a single communication cycle. In code,
for example:

MyQuery.RemoteReadSize := 50;
MyQuery.Open;
while not MyQuery.EOF do
begin
  //do something, add client name to ListView, for example
  MyQuery.Next;
end;

The query component will grab 50 records at a time from the server, not
just 1. If you have 200 records, instead of 200 fetches you have just 4
fetches (of 50 records each). This saves a hell of a bunch of time!


Robert wrote:
> "Jason Lee" <computerguy@wavecable.com> wrote in message
> news:067A37E1-638A-4F9C-A2F9-3A195D293EE6@news.elevatesoft.com...
>> C/S mode is faster when Query.RemoteReadSize is set.
>>
>
> Thanks for the feedback. Are the defaults documented soemwhere?
>
> Robert
>
>
>

Robert,

<< 1. It seems that C/S is consistently faster in V4 than fileserver (was
not the case in V3). Is that everybody's experience? >>

Well, it depends upon what the application is doing, and especially if
you're using a lot of SQL in the application.  C/S is faster with SQL in
version 4.

<< 2. I'm tring to determine a good backup setup (right now I copyfile each
DAT and IDX file) using the new backup and restore methods. Questions are:

2.1 In C/S, can I use a Database as backup destination? It seems silly to
have to code a path in C/S mode, one should set all that up using the
> database administrator. >>

No, you have to give it an actual path name.  Most of the time backups are
executed from the context of the database server machine, either on demand
or in a scheduled event.

<< 2.2 Can I use the same backup/restore methods when running C/S or
fileserver? >>

Yes.

<< 3. Is it necessary to do something special to keep the server connection
open when the terminal is inactive? If so, what? >>

It's not absolutely necessary, but if you want the connection to never time
out and be removed by the database server unless the client app/machine has
actually been shut down, then set RemotePing to True.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jason,

<< The default for RemoteReadSize is 1. Only one record will be fetched at a
time. This means the client must communicate with the server if you want the
next record fetched. If you set RemoteReadSize to 20, however, then 20
records are fetched in a single communication cycle. In code, for example:
>>

Just one small addition - DBISAM will automatically adjust the default of 1
to the number of rows in a multi-row control if the DBISAM table/query is
being used in a multi-row control like a TDBGrid.  It just does this "under
the covers".

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:25A9860E-8B60-420E-8F69-68BCAC883867@news.elevatesoft.com...
>
> 2.1 In C/S, can I use a Database as backup destination? It seems silly to
> have to code a path in C/S mode, one should set all that up using the
>> database administrator. >>
>
> No, you have to give it an actual path name.  Most of the time backups are
> executed from the context of the database server machine, either on demand
> or in a scheduled event.
>

Hmm, maybe I don't quite understand what you're saying but in my case, the
backup happens at a workstation. In fact, nothing is "run" at the server, in
the sense that all user interface happens at a workstation.

Using the Admin program, I can equate a database folder to an alias, so that
regardless of mappings, the workstations all access the same physical files.
That's the way it should be. But for backups, each workstation will have to
have an actual path. Not consistent.

It is not a big deal, I've been dealing with it fine in file server by
always using UNC so I don't have to depend on individual terminal mappings.
But unless I'm missing something, it seems to me that the backup location
should be part of the database setup. Just as you determine that for this
database the files are on a specific folder, you should also determine thet
the backups go to a specific folder. Just to be consistent.

Robert

Robert,

<< Hmm, maybe I don't quite understand what you're saying but in my case,
the backup happens at a workstation. In fact, nothing is "run" at the
server, in the sense that all user interface happens at a workstation. >>

In that case you'll need to make sure that the the workstation specifies a
path that is accessible to the server machine.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:B0D2EB80-C627-409F-BF58-C90932F95FE9@news.elevatesoft.com...
> Robert,
>
> << Hmm, maybe I don't quite understand what you're saying but in my case,
> the backup happens at a workstation. In fact, nothing is "run" at the
> server, in the sense that all user interface happens at a workstation. >>
>
> In that case you'll need to make sure that the the workstation specifies a
> path that is accessible to the server machine.
>

I understand that, I just don't think it's right. There is no reason
workstations should have knowledge of "path that is accessible to the server
machine". Just as I tell the server to open database alias so and so and the
server knows where to find the data, I should be able to request a backup
and the server should know where to store the result. At least have an
option to tell the backup "put the file wherever the tables are". Otherwise
I'm stuck with ini files with hardocded paths even in a pure C/S mode, plus
changing from one database to another becomes a drag. Oh well, one can live
with that, but it would be nicer if the option were there. I guess I can
modify the server to read a server ini file.

Robert

FWIW, I agree. You should be able to tell the server to use an alias,
which would be stored with the server in something like alias.ini. Thus
save to "$backup\myfile.bak" would lookup in alias.ini:
backup=c:\mybackup
and end up in c:\mybackup\myfile.bak

The ideal would be that these could be set per database and by code.
Perhaps a wish for ElevateDB?

/Matthew Jones/