×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Which, of course, is designed to act as a simple way to solve the
initial problem of colliding updates.
The more I follow this thread the more convinced I am that the simplest
solution is to compare the before and after values of the specific
field(s) in question. Its easy, its clear, and it deals with the actual
data and not on some hazy smoke signal from a field far away. Saving
the field's initial value is really not that many lines of code;
certainly it is less than what is apparently involved in getting &
setting unique timestamps, computing micro-seconds, and with having to
update micro-seconds.
To compare before & after, I use a variation of either a 3 data
structures defined like the record involved, or if its a record with
many fields and I am interested in just a few fields, a data structure
of just the fields I care about. the 3 data structures are: Original
(prefix("Or_)"), the record, and New prefix("Nw_')).
Then, I read the record, load (Or_) and the screen fields, do the screen
work, load (Nw_) and get the record again and compare for changes.
Thats pretty straight forward and does not concern itself with timestamp
fields, or with false positives (a different field was changed at
another work station).
On 12/22/2017 7:43 AM, Raul Jager wrote:
The initial reason to suggest row change is to know if the row has
changed between the time it was read to display and the time it is read
to update.
midrange.com
