So using standard networking code for tables and forms, do the templates/library code leave a hole in the integrity of the system whereby data can be lost as follows?
User 1 presses INSERT to create a new autoincrement record
User 2 sees the “dummy” record and double clicks to edit it. Fills it in, maybe adds child records. Possibly goes in a few times adding even more info and perhaps printing it etc.
User 1 comes back to their screen and hit ESC or clicks cancel - this deletes the record!
Of course, if two users EDIT the same record, the templates/library code check for “changed by another station” - but not in the above scenario!
Is this indeed the way the system is, and if so, has anybody already dealt with it cleanly (templates/class improvement) and is willing to share?
(I would try to have the CANCEL check for changes in the record on disk and/or at least warn users not to edit anything that looks like a dummy record that might still be in the process of being inserted.)
Not in windows, But had exactly this scenario in the DOS days. Got around it by putting ‘Inserting record’ in the description field so people would know.
You could also use a field as a lock, so if it’s blank you can’t edit that record, and after insert you put something in there.
I’ve also used a technique where you have a duplicate set of edit tables. Inserts and edit take place there and are then copied into the real tables.
My 2 cents. Move to an SQL back end and put these considerations to rest. Once free of tps, it is amazing what one can accomplish without even giving up the shipping ABC templates.
Usually you’ll have some other fields that are required before saving but are Zero or Blank in the placeholder. I will use those fields to filter the placeholders in Validate Record.
Sometimes I show them for my Back Door user (or with a hot key) so if there was a crash before the add was completed I can delete the placeholder.
This is what I meant by “not to edit anything that looks like a dummy record”, but I am shocked that the standard Clarion code, which handles “changed by another station” so well on normal edits, apparently has this gaping hole, and it’s been there for over 30 years now. I thought maybe I was missing something.
Then I thought, someone must have written a template-base fix…
This is a very serious flaw in the “standard model”, with potentially severe ramifications in a business.
“Change by another station” is probably also very rare, but that’s been built-in since version 2.0 for DOS, if I’m not mistaken. I can manually code solutions for each table. However, I do think that this situation should handled by the basic generated code, just like the regular “Change by another station” situation.
Most of my keys have the attribute to suppress zero/space values so these place-holder records tend to be invisible in typical browses that may be organized by a name or code since the place-holder record doesn’t appear in the key. I don’t remember if that was the default for new keys or I just always did it that way. FWIW, I’ve never had a reported issue with the scenario and I’ve run in multiple sites with lots of users.
So, the theoretical problem exists, but in practice doesn’t appear to happen enough to notice.
