Hi Kirk,

The program is currently single-user. I did include load-wait and unload type 
record handling which I use on server applications.

I considered variables. It might run faster, too, though I don't know how 4D 
manipulates records within transactions. Ssince it's happening in memory, they 
might already be using variables. 

I'm using separate methods to identify missing/unavailable data, calculating or 
using substitute techniques, and writing warning/error messages. I had hoped to 
use them as building blocks, so I would not have to duplicate the logic in 
another place. But I could re-write, it might not be as bad as it seems at 

I'm still wondering why 4D holds the wrong field contents at the end, after 
rolling back the transaction. Just doesn't seem right.

Thank you for the detailed comments,

>Hi Don,
>A couple of thoughts. First, and I'm assuming this is running on 4D server,
>I'm not a fan of opening a record for editing in a transaction when you
>also manipulate other records. This example illustrates why - each record
>you touch in becomes locked to the transaction if you change it and if the
>user walks away from their workstation (or goes home) it's a real problem.
>In such a case I prefer to set a semaphore for the record (eg.
>"[table]_edit_[recordID]" ) to prevent anyone else from working with it and
>then save the final changes.
>Regardless of that I'd do this sort of calculation entirely in variables.
>Just load all the record data into the arrays and manipulate those. When
>you have a solution you can update the underlying records. For your items
>you only need the id, and cost to identify it. Even if you need more I
>think the 'cost' of loading that data into arrays is trivial compared to
>manipulating the records directly.

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to