Gordon,

<< No.  The customer decided to perform some additional functions while
recording the log.  I assumed that if there was a problem, it would jump out
as a long delay in the log itself.  I can have him generate it again with
just the startup and shut down, or is there a way to programatically stop
the log once the application as completed the startup process. >>

The issue isn't one of a particular request taking a long time, but the
result of many requests causing too much latency due to the request/response
cycle.  There's a lot of chatter in there, but I need to know where the
application startup stops so that I can determine how much is unnecessary
chatter.  One thing I see, for example, is a lot of calls to the Exists
method and a lot of calls to properties on tables when the table isn't
actually open.  I assume that these are calls for structure and version
checking, etc.  You may want to consider moving these to the actualy server
itself, because there isn't really a need to have each application startup
check these things when the server actually controls them anyways.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> The issue isn't one of a particular request taking a long time, but the
> result of many requests causing too much latency due to the request/response
> cycle.  There's a lot of chatter in there, but I need to know where the
> application startup stops so that I can determine how much is unnecessary
> chatter.  One thing I see, for example, is a lot of calls to the Exists
> method and a lot of calls to properties on tables when the table isn't
> actually open.  I assume that these are calls for structure and version
> checking, etc.  You may want to consider moving these to the actualy server
> itself, because there isn't really a need to have each application startup
> check these things when the server actually controls them anyways.

The app was "ported" from the shared file version of the program, and so
it checks to see if the tables exist during start up.  If not, a screen
is displayed so the customer can re-create any missing files.  Any
changes to the database structure (new fields or indexes due to an
update) are also performed at this time.

So, in general, to move this code to the server, I would create a
procedure (CheckDBFiles) that would perform this process and send a
message back to the client in a RemoteParm value.  Is this correct?

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

Gordon,

<< So, in general, to move this code to the server, I would create a
procedure (CheckDBFiles) that would perform this process and send a message
back to the client in a RemoteParm value.  Is this correct? >>

You could do it that way, or simply have the server check at startup time in
the FormCreate for the main form of the server.  The benefit of doing it at
server startup time, is that it is done once and that's it.

--
Tim Young
Elevate Software
www.elevatesoft.com

As I'm looking into this deeper with the customer, application startup
is only part of the problem.  The program does a group of calculations
that perform a number of database queries.  Since it's all using shared
file commands (rather than SQL commands) I'm not sure exactly how much
network traffic there is between the client and the server.

I'm using the FindKey, FieldByName, and Filter properties to retrieve
data and perform the calculation.  But I'm not sure how these commands
translate to networking requests of the database server.  But at about
63 msecs per REQUEST_something, the time to perform my calculations can
add up rapidly.  (Over a 100MB LAN in shared file mode, it takes a
second or two.)

So for those of you who are doing CS applications over a WAN, how do you
handle database intensive calculations and still get good response time
from the user perspective?  (A rule based calculation where the rules
are stored in tables, earned vacation time for example.)

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

Gordon,

< I'm using the FindKey, FieldByName, and Filter properties to retrieve data
and perform the calculation.  But I'm not sure how these commands translate
to networking requests of the database server.  But at about 63 msecs per
REQUEST_something, the time to perform my calculations can add up rapidly.
(Over a 100MB LAN in shared file mode, it takes a second or two.) >>

FieldByName won't be an issue, but FindKey or modifying the Filter property
will result in one or more messages to and from the server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> FieldByName won't be an issue, but FindKey or modifying the Filter property
> will result in one or more messages to and from the server.

Just so I understand more, in the CS version, the FindKey is the
equivalent of select * from table where keyvalue = x.  Is that why the
FieldByName doesn't send messages?

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

Tim Young [Elevate Software] wrote:
>
> FieldByName won't be an issue, but FindKey or modifying the Filter property
> will result in one or more messages to and from the server.

I ran the log for the kind of calculation I was referring to, and there
were 913 Request/Reply pairs for that process.  Locally, the delay time
was usually less than a msec, but over a WAN with some latency,
performance would plummet.

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

FieldByName is a method of TDataset. It just finds the TField in
TDataset.Fields with the passed name.

Sean

Gordon Turner wrote:
> Tim Young [Elevate Software] wrote:
>>
>> FieldByName won't be an issue, but FindKey or modifying the Filter
>> property will result in one or more messages to and from the server.
>
> Just so I understand more, in the CS version, the FindKey is the
> equivalent of select * from table where keyvalue = x.  Is that why the
> FieldByName doesn't send messages?
>

Gordon,

<< Just so I understand more, in the CS version, the FindKey is the
equivalent of select * from table where keyvalue = x. >>

Well, it's a little more direct than that and there isn't any SQL involved,
but yes, that's the general idea.

<< Is that why the FieldByName doesn't send messages? >>

FieldByName is a standard method, as Sean indicated, and works by using one
of the record buffers that has already been retrieved from the server, hence
it doesn't need to make any requests to the server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gordon

> So for those of you who are doing CS applications over a WAN, how do you
> handle database intensive calculations and still get good response time
> from the user perspective?  (A rule based calculation where the rules
> are stored in tables, earned vacation time for example.)

I am just going through a very similar excercise to you.  In my case I would
have a process like (psudeocode)

Person.First;
While not Person.Eof do
begin
 if Allowances.Findkey([Person.AllowanceType]) then
 begin
   Person.Edit;
   Person.Allowance := <calc involving person and allowance record>
   Person.Post;
 end;
 Person.Next;
end;

Changing it to a query which went

UPDATE Person SET Allowance = <calc involving person and allowance record>
FROM Person
JOIN Allowances ON Person.AllowanceType=Allowances.AllowanceType

cut the chat down to nearly zero and gave a huge speed increase.

If your calcs are to complicated for an SQL statement you might need to
create a server side procedure.

Cheers

John