Hi Mel:

There appear to be a few contradictions in what you are asking to do. It may be that you haven't quite asked the question correctly.

>I have a Form that uses a view (no grid), and when I press Next/Prev/etc. button on toolbar I would like the View to be updated with the underlying table data (just for that one record in case a change was made by another user - I am not wanting to requery the complete view).

This is the contradiction. You say "just for that one record". Do you mean the record you are on originally, or the record you are moving to after pressing the Next/Prev button? By selecting these buttons, you are telling Codemine that you want to move away from the "current" record? Consider the following :-

When you first load data into the view and the view effectively becomes the form's datasource, it is simply a snaphsot of the data in the underlying table at the time you originally queried the view. If you can imagine a couple of users using the form, they will each have their own disconnected snapshots of the data. Each instance of the view on each workstation will not know of other users changes until a couple of things happen :-

1) Any user who has made changes to the data in their view saves the changes. The save options instigates a tableupdate() back to the underlying table datasource.

So far so good. However, any other user will still not know about changes made to the source because they are still using their original view "snapshot". So, for the subsequent users to get the latest changes made by other users on the network, they need to :-

2) Save any of their own changes back to the source table, Save->TableUpdate (in the framework) and then Requery the source table to get the latest changes made by other users reloaded into their view snapshot.

>I tried putting:

=REFRESH()

>in the rulecustom.AfterNav() or the datamanager.AfterNav(), but it only refreshes that record in the view if I move to that record, then off that record, and then back to that record.

The above command will only refresh the form and not necessarilly requery the view. By moving off the record and then moving back to it, depending on the buffer mode, you will simply get a form refresh() from the underlying view data, not a view refresh from the underlying table data - that would require a requery().

If you have the view's buffermode set to '3', then moving the record pointer in the view will automatically commit any changes to the data you have made automatically. If it is set to '5', then moving the pointer in the view will not commit the changes until you expressly Save the changes in which the framework will call a tableupdate().

The big question here is that you seem to suggest that you want to see changes made by other users to the record you are currently on. Is that right? The usual scenario is this. When two or more users are on the same record in a view on different workstations, each user doesn't know about other users changes until they try to save their own changes to that record. This is the classic "contention" situation. Your code needs to handle the situation where you are updating the your copy of the record and the view update detects your changes will overwrite another users changes that have been made to that record since you originally loaded it into your view.

Thats pretty much how it happens in a view. The only way you will get your record copy to reflect other users changes to the same record is to the requery the whole view and relocate to the record by its PK (primary key) after the requery has occured. Otherwise, it may be that the scope of your view is too wide. Maybe you should restrict your view to a single record (as opposed to a whole record set) so that a simple "Requery" can be processed that will only pull back the current record over the wire. Obviously, you would not be able to Prev/Next etc because there would only be one record in the view. This is where you would have a lookup routine that specifies the value you want for the next record and the view requeries with a WHERE clause based on your "next record" lookup criteria.

All this is probably not going to answer your question but it should allow you to rethink how views are working and then re-ask the question <s>. Lets take it from there ...

HTH