Hi, Vlad.

Thanks for the thorough reply. You mentioned a couple of items I hadn't even thought about regarding the parameters. I'm not quite sure what I will do about all that.

Prior to starting this class, I'd also given some consideration to what you said about CREATEOFFLINE. Here's what I came up with (feel free to set me straight):
1. The original purpose was to give one of my applications "data synchronization" capabilities. The target audience is a specialized group of lawyers who would benefit from being able to go on the road with a notebook, and then upload their updates to the main system. The users have been asking for this particular feature since 1994.
2. Years ago, I'd read some articles from other gurus about how to create a scheme very similiar to what you are suggesting. But, wow! It sure was a massive undertaking. I was never confident I could implement it without introducing massive problems into an otherwise stable system.
3. I recently found an article/zip by Doug Hennig at the Stonefield site about how to implement a system similiar to what I wanted using CREATEOFFLINE. I've completely overhauled that class to make it more robust and generic.
4. The added benefits to using the class are: a system administrator can perform a PACK/REINDEX, without having to kick anyone out of the application; and, I can upload the class to the files section so that any developer can pop it into their application.
5. I had been previously warned to worry about data collisions using CREATEOFFLINE. But, I must be dense: I'm not seeing what is different about this scheme that using a system similiar to what you suggest would prevent. For instance, using the application as it is now without any offline capabilities, User A could change the phone number for Person X; one minute later, User B could change the phone number for Person X. That seems more of a procedural issue than a programmatic one.

Thanks again for your reply!

-Bri.


>Hi!
>
>Get the SQL statement of the view and find all '?'. Well, a bunch of processing is required because view accepts parameters like 'alias.Fieldname' or 'object.object....object.property'
>
>Instead of CREATEOFFLINE, I would suggest you to use COPY TO command and copy data into the table, than add fields to track changes in that table. When going online and updating the main database, use these fields for tracking changes to update data on the server. This way you can also track the collisions that is not available for offline views. More reliable and no problem with parametrized views. Well, this require to make your own data handling class that will be aware of the offline state and store required information about changes...
>