Bruno.

I have followed your coding and the load speed is reduced to close on 1 minute. Whopee.

I have put the two tables that were causing speed problems into memory.

I'm not too sure how I handle the AutoInc fields.  I have put them as Integers as you suggest.  When a new record is inserted I will post it back to the remote server using an INSERT statement.  Is that correct?

How do I get the AutoInc created on the server to put in the integer field on the Client machine?

Do I do an INSERT to the remote server in the BeforeInsert event of the memory table?

Thanks.

Rob.

Robert,

<< I'm not too sure how I handle the AutoInc fields.  I have put them as
Integers as you suggest.

Do I do an INSERT to the remote server in the BeforeInsert event of the
memory table? >>

That's a bit of an issue normally, and yes, that is the only way to actually
have the two tables synched up.

--
Tim Young
Elevate Software
www.elevatesoft.com

I'd like to thank everyone for their help in respect of this issue.

For anyone following this thread this is what I think is the way forward.

Firstly, reduce the number of records loaded to a remote client  My application is for running an Architectural or Engineering design office.  I now only load Current jobs to the client machine.  That reduced the jobs from 3,000+ to around 100.  There are a considerable number of support queries and all are linked by a Master/Detail relationship to the jobs query.

Create local memory tables using SaveToStream/LoadFromStream to get the records from the server.  In my application this also helps reduce chatter as it is frequently seeking information from the tables/queries.

I haven't quite figured this out yet but I'm pretty sure that if the table opened on the server (and then streamed to the remote client machine) is left open, then if a record is changed by someone else I will get a 'record has been changed...' warning when using the same table to post changes.

I've yet to make further changes based on the above but the load time is down to a minute.  Performance is poor in some respects but I feel if I'm prepared to have another 30 secs on the load time then the application will then perform almost as quick as being in the office.

My office upload speed  is around 0.5Mb and this cannot be improved.  SDSL will not be available in the office exchange for quite a few years (in fact it is not planned).  If I could get it I think the upload speed would increase to 2Mb which would make for a much quicker application load.

Robert,

<< Create local memory tables using SaveToStream/LoadFromStream to get the
records from the server.  In my application this also helps reduce chatter
as it is frequently seeking information from the tables/queries.

I haven't quite figured this out yet but I'm pretty sure that if the table
opened on the server (and then streamed to the remote client machine) is
left open, then if a record is changed by someone else I will get a 'record
has been changed...' warning when using the same table to post changes. >>

Yes, that is correct.

If you're going to use SaveToStream/LoadFromStream between a table on the
server and a local in-memory table, you should consider just using cached
updates.  That's basically how they operate, and they do all of the work for
you.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<< If you're going to use SaveToStream/LoadFromStream between a table on the
server and a local in-memory table, you should consider just using cached
updates.  That's basically how they operate, and they do all of the work for
you. >>

Just when I thought I was getting on top of things....

I've looked at the manual and also searched for cached updates and am struggling to see how I get the table or query to be copied into memory of the remote client machine.

Am I right in assuming that once it is in memory and connected to a grid or whatever, that I use the application as usual and whenever I want changes to be sent back to the remote server I use ApplyCachedUpdates?  And this updates only changed records?  So I could use ApplyCachedUpdates in the OnScroll event of the remote in memory table or query and not have to do any other coding?  Whopeee.

Is there any chance of a teeny weeny example to get me going?

Robert,

<< I've looked at the manual and also searched for cached updates and am
struggling to see how I get the table or query to be copied into memory of
the remote client machine. >>

BeginCachedUpdates does this:

http://www.elevatesoft.com/manual?action=viewmethod&id=dbisam4&product=d&version=7&comp=TDBISAMDataSet&method=BeginCachedUpdates

<< Am I right in assuming that once it is in memory and connected to a grid
or whatever, that I use the application as usual and whenever I want changes
to be sent back to the remote server I use ApplyCachedUpdates?  And this
updates only changed records? >>

Correct.  However, once you apply the updates, you'll need to call
BeginCachedUpdates again to put the dataset back into cached updates mode
and retrieve the updated rows back from the server.

<< So I could use ApplyCachedUpdates in the OnScroll event of the remote in
memory table or query and not have to do any other coding?  Whopeee. >>

Basically, yes.

<< Is there any chance of a teeny weeny example to get me going? >>

You can find one here:

http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=d&version=7&topic=Cached_Updates

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim.

I'm fearful of sounding a little stupid here as I'm somehow missing the point.

I add a table, MyTable, to a form.

I set the Session, database and table name on the Server

I then run the application (on the remote client) and call MyTable.BeginCachedUpdates.  Is this correct?

The resulting data is now stored in memory on the remote client machine.  Is that correct?

If so, how can I access it in memory?

On the methods, does BeginCachedUpdates reload all the data from the remote server?  Can Begin and ApplyCachedUpdates be in threads?

Sorry to hassle.  I had read the help file but could not see how it all fits together.

Robert,

<< I then run the application (on the remote client) and call
MyTable.BeginCachedUpdates.  Is this correct? >>

Correct.

<< The resulting data is now stored in memory on the remote client machine.
Is that correct? >>

Correct.

<< If so, how can I access it in memory? >>

You don't have to - it replaces your "view" of the data in the TDBISAMTable.
Instead of looking at the live server data, you're now looking at the local
data.

<< On the methods, does BeginCachedUpdates reload all the data from the
remote server? >>

Yes, so you only want to do this on tables that aren't particularly large.

<< Can Begin and ApplyCachedUpdates be in threads? >>

Only if you use proper isolation and make sure that nothing else is trying
to access the same table at the same time.  This is virtually impossible
with the way the TDataSet architecture works, so I wouldn't try it.  Just
showing a form that has data-aware controls on it will cause access to the
table component, and access that you cannot control or prevent.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Robert

> The resulting data is now stored in memory on the remote client machine.  Is that correct?

It isn't in memory, it is in a temporary table on the remote client machine
(but I believe Tim is considering changing it to use in-memory tables).

Rob

Rob,

<< It isn't in memory, it is in a temporary table on the remote client
machine (but I believe Tim is considering changing it to use in-memory
tables). >>

Correct.

--
Tim Young
Elevate Software
www.elevatesoft.com