Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Getting View Parameters
Message
From
30/07/2001 05:39:21
 
 
To
27/07/2001 13:00:32
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00536191
Message ID:
00537089
Views:
26
This message has been marked as a message which has helped to the initial question of the thread.
Hi!

>
>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.
>

This is called "Replication" and it is quite hard to make it as generic as possible. Take a look to the SQL Server replication and see how it is complex, here gurus are right. However, for single particular application when everything is on your control it is not that hard. I thought it would be better to develop your own small replication algorithm instead of workarounding offline views. For me the first thing is less complex than second. With custom program you also will be able to better organize things special to the application, like collisions managing to, for example, merge memo fields in case 2 useds changed memo field simultaneously etc. With generic approach and offline view it might be quite complex.

If you want, I can spend my free time and write a simple replicator for VFP database, but tell on which basis it should work: timestamp or full match. Timestamp is the best approach, when each table have a timestamp field and application updates this field each time changes are made (this coul be done by default value for new records and update triggers in VFP database). Second approach is more generic and complex and have less performance, because it searches changed records using exact field to field match.

> 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.
>

Can you give ma a link?

> 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.
>

With replication it will be the same...

> 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.
>

VFP have built in functions which you can use to manage collisions just before the update of the data. Tableupdate() with .F. option will try to update with collisions aware. If it failed, analize oldval(), newval() and current values to see what fields are changed, show warning to user and ask if overwrite or not. This is as simple as it could be. When working offline (or through replication), this is the major problem. Good replication process should be aware about collisions and do something about them. For example, write collision records separately, or define the priority list for users whihc user changes are the most important. For memo fields that collect certain text information perform merge. For new records generate new ID values and update ID values accross the related tables, in case you do not use GUID approach.

>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...
>>
Vlad Grynchyshyn, Project Manager, MCP
vgryn@yahoo.com
ICQ #10709245
The professional level of programmer could be determined by level of stupidity of his/her bugs

It is not appropriate to say that question is "foolish". There could be only foolish answers. Everybody passed period of time when knows nothing about something.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform