I've noticed in several different scenarios over the last few years that when data is updated through a TCursor in OPAL, it may take hours for the change to become apparent in other instances of the application referencing the same tables. In earlier cases this was difficult to see because it's intermittent and you have to look at different computers to notice. But in the latest case it's easy to demonstrate.
I have a timestamp in a table that's updated by one instance of the app every 15 minutes. All other machines check this timestamp every time a user logs in to the app, and notify the administrator if the "master" instance is not updating the timestamp.
What I've seen is that even though the master is updating the table consistently, the workstations see the old value. Sometimes they do see the new value right away, but many times they don't see it for hours or even days (during which time the master has updated it multiple times).
I have had the same table open in a table view in Paradox (i.e. not in the application) on two screens (master and workstation) side-by-side, with different values showing. I can go into edit mode on either machine and it doesn't reconcile the value. But if I go into edit mode on the workstation, manually edit some other value, and end edit mode, then the timestamp reconciles itself between the two views.
Note this doesn't have anything to do with the network refresh value - I can open and close the tableview as many times as I like and the inconsistent values still come up. It seems to be related to some kind of data caching going on in BDE. Also it only happens when the value is changed by OPAL - on a user edit the values update immediately across the network.
The TCursor is closed after each edit. It is also local to the timer event, so it goes out of scope each time as well. This is in Paradox 9 on Windows 2000 Pro workstations. The "master" is running on Win 2K server.
I have a timestamp in a table that's updated by one instance of the app every 15 minutes. All other machines check this timestamp every time a user logs in to the app, and notify the administrator if the "master" instance is not updating the timestamp.
What I've seen is that even though the master is updating the table consistently, the workstations see the old value. Sometimes they do see the new value right away, but many times they don't see it for hours or even days (during which time the master has updated it multiple times).
I have had the same table open in a table view in Paradox (i.e. not in the application) on two screens (master and workstation) side-by-side, with different values showing. I can go into edit mode on either machine and it doesn't reconcile the value. But if I go into edit mode on the workstation, manually edit some other value, and end edit mode, then the timestamp reconciles itself between the two views.
Note this doesn't have anything to do with the network refresh value - I can open and close the tableview as many times as I like and the inconsistent values still come up. It seems to be related to some kind of data caching going on in BDE. Also it only happens when the value is changed by OPAL - on a user edit the values update immediately across the network.
The TCursor is closed after each edit. It is also local to the timer event, so it goes out of scope each time as well. This is in Paradox 9 on Windows 2000 Pro workstations. The "master" is running on Win 2K server.
