>>There are a few different ways to accomplish this.
>>The way I most recommend would be to use input parameters
>>instead of trying
>>to locate. This way you are just fetching the record(s) of
>>interest only.
>
>
> But I have to be able to add new records to the table and on this way I
> understand this could not be possible, isn't it?

You can still add new records. The 'problem' may be seeing
the new ones after a refresh. On a slow connection, the plan
should always be - only access the records you NEED.

>>To get emulation of smart buffering you can try two options.
>>
>>#1: Set FetchWholeRows to false. (vertical dataset partitioning)
>
> Done!
> It's a great improvement? Is there any side effech I should know?

See note above. All you are doing is moving when the client
looks for and downloads records that they may not even need.
If you scroll down the whole list, all the records then get
transfered - but as you scroll.

>>#2: Use POS attribute of OrderingLinks property (horizontal dataset
>>partitioning)
>>
>
> Sorry. I can't imagine how to do that and I can't find additional
> information.

It is a little difficult to find ( any Tech Sheet on this
Helen ? ). Again though, it is just reducing the amount of
data that is accessed in a query. You may need to think
about providing a search facility on the client, and only
handling a sub-set of the records that way.

I try and keep access over the slow links to a single
record, and then maintain a copy of the historic data
locally so that the client can still scroll, but the data I
am working with only changes slowly as well. Any update to a
record on the main database is then copied to all the local
copies.

Just another way of doing things - and it carries on working
when the connection is down - just need to take care with
updates after the link is restored.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services