>Hi Erik,
>
>Yes, it was the same message posted twice...
>
>I am trying to follow Doug Henning's advice in his "Implementing Offline Views" article, and it works... sometimes. It may be that I'm doing something wrong - most likely -, or the OL views are unstable.
>
>Is there a better alternative for disconected data entry?
>Why do you think there are so few using OL views?
>
>Thank you for not having me on you twit list yet.
>Doru.

Obviously I'm not Eric, but yes there are alternatives to offline views.

select your data into a table (use a naming convention or a little local to the users machine dbf to keep track of the temporary table. After the user makes change and reconnects, write the changes back.

Obviously the write back takes place within a transaction.

As a simple case you can end up with optimstic record locking by doing to following:

1) write back only to cases where the record has not changes since you downloaded it.

2) detect whether any records were not written back.


Among simple ways of handling conflicts when detected.
1) End the transaction of any changes went through. This is for the rare cases where the record set is not really a unit, and you can change some records and not others and cause no problems.
2) Roll back the transaction if any changes happended at all (the other extreme) where the write should completely succeed or completely fail as a unit. It is actually pretty common that you would want to do this.
3) Beyond this you can write as fancy a handler as you wish. -- for instance showing users old and new values and giving them a choice of whether to overwrite. I actually usually don't care for this, but there are cases where it is appropriate -- so my "not caring for it" really just means that it has not been applicable in most of my apps.