I am going to post here a response I got from Tim Penner in the TAOW a bit earlier today. While it does not change my mind that this issue should be characterized as a bug, it does clarify what the issue really is.
Am I the only one that was clueless that there is a field dirty field flag that controls whether or not a field gets updated or not during a save record. Guess that does make sense. John --------------- Hi John, It's not a dirty flag for the record, but a dirty flag for the field. The object field has a dirty flag that only gets set if you reference the object field itself (not a property of it). Here are some examples to help illustrate the difference: OB SET([Table]OBField;"Prop";"Val") // references the object field itself and does set the dirty flag for this object field. [Table]ObField.Prop:="Val" // references a property of the object and will not set the dirty flag for this object field. OB SET([Table]ObField.Prop;"Property2";"Val2") // references a property of the object and does not set the dirty flag. [Table]ObField:=[MyObject]ObField // references the object field itself and does set the dirty flag for this object field. To be clear, in the example database that I submitted with my bug report I demonstrated, as you demonstrated in your last update, that other fields were being saved and that only the Object Field data was being lost. I even demonstrated in code that the change to the object field appeared to stick after a SAVE RECORD and it only reverted to its original state when the record was reloaded. Because of this i categorized the report as a Data Loss bug and made the data loss part clear. Today, (after i noticed it was marked as standard behavior) i requested that our documentation be updated so that we can hopefully prevent further reports of data loss. Regards, Timothy PENNER -------------- > On Oct 31, 2017, at 2:39 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > On Wed, Nov 1, 2017 at 10:23 AM, Tim Nevels via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > >> I can guess the answer to that. The engineer responsible looked at the >> code and said, “yeah I can fix that, but it will be a lot of work”. And >> somebody said, "OK then don’t bother. You’ve got more important things to >> do. We’ll just call it ‘Standard Behavior’”. Pitiful! :( >> > > We'll never know. It could be that it is the result of a carefully thought > out design. > > Then again, you could have a function like Add(2;2) that returns 5 and > claim that it's "standard behavior" because it's consistent. No matter > what, it's still a bug (except for sufficiently large values of 2.) > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** John Baughman Kailua, Hawaii (808) 262-0328 john...@hawaii.rr.com ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
