>>Assuming I understand this right - it does sound like something I've done in the past - and it was a real pain to get it to work - but it turned out really nice.
>>What I did was:
>>1. First I used remote views for everything - and created a classlib with a timer in it.
>>2. Anytime a view is requerried, I kept track of the parameter(s) that were used to requerry the views. I did this by keeping an array in that class that kept all the view names, variables, and values for those variables used to refresh the view.
>>3. ThenI put this class on each of my forms. Now if the user is NOT in 'edit mode' - I would run the timer gizmo every x seconds (or minutes, depending upon their requirement) - and it would auto-reuqery all the views and refresh the form. If all the data was the same - then no big deal , leave everything alone.
>>4. Now if the form had gone into 'edit mode' - and now you want to save - then it's necessary to check for conflicts - which my gizmo did also - and then would popup a screen showing the differences and would allow the user to pick which update (s) they wanted to keep.
>>
>>I spent a HUGE amount of time on this back in around 2001 or 2002 - and it really came out quite nice - one of the things I'm more proud of actually. I really should it in the downloads section sometime but the code was pretty hard to follow and I didn't want to be answering a zillion questions about it so I never did.
>
>Something like... and wow, this is heavy artillery, in comparison with my scenario. You were checking for edits potentially done by others. This is, well, one thing that this should do, i.e. check for changes in the lookup table and refresh that one view (i.e. the lookup alone) and leave everything else as it was (for which he can't find a way, it's refresh all or nothing or he can't find the switch).
>
>This is simpler but more specific. Assume form A (order entry) needs a customer, launches search form (B, customer search). While in form B, the user finds that some customer record editing must be done (address change perhaps) or the customer simply isn't there. So either form B can edit, or it launches C to edit the customer record. Saves, returns to B, which is requeried and now shows the newly changed record (by this user, and potentially by others). Returns the PK to A, which still has a cursor (or rowset or whatever they have) which now has old data - one record in it may be missing or old. I fox, we'd just requery that one cursor and display a few fields from the latest and greatest record from it. He has a problem even finding a description of such a scenario.

Ok - so in a way it's pretty similar - my gizmo handles this as well. For the lookups - a trick is to use a modal form for editing the lookup list - then when you close that form - the underlying form that called is requries the lookup view. Sharing data-sessions and perhaps even using the same view and same datasession are little tricks you can do to make this happen.
I really went off the deep-end on one application I did to deal with this. I used the StoneField Database Toolkit to store a bunch of meta-data - then I created a class for all my lookup fields - if you right-clicked on it - then a form was dynamically created to do data-entry on the lookup table based on what was in the SDT meta-data tables (so you could dynamically create a textboxs or a checkboxs, datefield, etc). That was a really nice piece of work, because it saved me from having to create what would of been close to 100 lookup screens. You combine that with the auto-requerying gizmo on a timer, and then the check-for-update-confilicts dynamic screens when saving - then you really got something pretty special. In my case doing all this was a big deal for the customer because they had too many situations where there was more than one user looking at the same dataset at the same time. Having the data auto-refresh on their screen every xx seconds saved them a bunch of problems they were having because of this. Years and years ago I showed the way I was using SDT and meta-data to generate my lookup-editor screens on the fly to Doug Henning and he was pretty impressed.