> OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty. > And, yes, I too was told that the engineers were leaning to declaring > this as standard behavior. Why? I have not a clue.
obviously I can't speak for "the engineers", but I would not rush to the conclusion that it is simply due to sloppiness. "standard behaviour" is a specific term that means the result is "expected, if not intended" by design or specification. in general (not just object fields), 4D has a way to not re-save a record if it hasn't changed. again, I have no idea "how" that is accomplished, but as a programmer, I imagine "why". it must be performance. I find it hard to believe that unchanged records are not committed to the data store, just by serendipity. it must have been designed to work that way. the question of course, is how do you know that an object field has been changed? do you scan every property and their descendants? what if only the structure has changed semantically? does that also count as a modification? on top of the parsing issue, re-saving an object field unnecessarily, would have a detrimental fragmentation effect on data file, now you might say, "why not increment an internal counter every time the object is modified" that would surely work with other large objects such as pictures, BLOBs, or text. but objects are references, so it is possible to modify the field without "touching" it. the object notation is one way to do that. but it is also possible using classic coding, whereby you obtain a reference to a sub object (OB Get), and modify that sub object. again, the "parent" object is not modified directly, so it is not updated with SAVE RECORD. to explicitly indicate that the object has been modified, just use the line [myTable]myObjectField:=[myTable]myObjectField and you have total control of when to save the field, which results in better performance, immediately as well as in the long term. to me this sounds like a better deal than a blanket "save always" system (the real sloppy design choice, in my opinion) ********************************************************************** 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 **********************************************************************
