[Warning] Settings properties values on object field by object notation

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[Warning] Settings properties values on object field by object notation

4D Tech mailing list
Hello,

If the value of a property is modified using object notation directly over an object field the modified value is not stored on the record.
This is reproducible in v16R4 and v16R5.


READ WRITE([Table1])
GOTO RECORD([Table1];0)  // [Table1]Object.value is False
$b_value:=True
[Table1]Object.value:=$b_value
SAVE RECORD([Table1])  // [Table1]Object.value is True after Save Record
UNLOAD RECORD([Table1])
GOTO RECORD([Table1];0)  // after changing the current selection by reloading the record [Table1]Object.value is false

I reported this to 4D via TAOW and the Forum.
4D answer was that is as standard behavior and they recommend me to assign the object field to itself after modification.

You can also use OB SET or assign the object to a variable and work with it before reassign it to the object field.

Alberto.



**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
Alberto,
doesn't Goto REcord ([table];0) - generate an error?
there is no record number 0

from documentation :
If record is less than the smallest record number in the database or greater than the greatest record number in the database


> Hello,
>
> If the value of a property is modified using object notation directly
> over an object field the modified value is not stored on the record.
> This is reproducible in v16R4 and v16R5.
>
>
> READ WRITE([Table1])
> GOTO RECORD([Table1];0)  // [Table1]Object.value is False
> $b_value:=True
> [Table1]Object.value:=$b_value
> SAVE RECORD([Table1])  // [Table1]Object.value is True after Save Record
> UNLOAD RECORD([Table1])
> GOTO RECORD([Table1];0)  // after changing the current selection by
> reloading the record [Table1]Object.value is false
>
> I reported this to 4D via TAOW and the Forum.
> 4D answer was that is as standard behavior and they recommend me to
> assign the object field to itself after modification.
>
> You can also use OB SET or assign the object to a variable and work
> with it before reassign it to the object field.
>
> Alberto.
>
>
>
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
------------
Hell is other people
     Jean-Paul Sartre
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list
I went through the same thing with TS. Tim will probably chime in.

The problem is that the dirty flag is not set when dot notation is used against an object field. In your scenario the following will work…

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.

So the workaround is not to  use dot notation against an object field, or to always save the object to itself before saving the record as that will also set the dirty flag…

[Table1]Object.value:=$b_value
[Table1]Object:=[Table1]Object
SAVE RECORD([Table1)

John


> On Oct 30, 2017, at 11:21 AM, Alberto Bachler via 4D_Tech <[hidden email]> wrote:
>
> Hello,
>
> If the value of a property is modified using object notation directly over an object field the modified value is not stored on the record.
> This is reproducible in v16R4 and v16R5.
>
>
> READ WRITE([Table1])
> GOTO RECORD([Table1];0)  // [Table1]Object.value is False
> $b_value:=True
> [Table1]Object.value:=$b_value
> SAVE RECORD([Table1])  // [Table1]Object.value is True after Save Record
> UNLOAD RECORD([Table1])
> GOTO RECORD([Table1];0)  // after changing the current selection by reloading the record [Table1]Object.value is false
>
> I reported this to 4D via TAOW and the Forum.
> 4D answer was that is as standard behavior and they recommend me to assign the object field to itself after modification.
>
> You can also use OB SET or assign the object to a variable and work with it before reassign it to the object field.
>
> Alberto.
>
>
>
> **********************************************************************
> 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:[hidden email]
> **********************************************************************

John Baughman
Kailua, Hawaii
(808) 262-0328
[hidden email]





**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
On Tue, Oct 31, 2017 at 3:49 PM, John Baughman via 4D_Tech <
[hidden email]> wrote:

> And, yes, I too was told that the engineers were leaning to declaring this
> as standard behavior. Why? I have not a clue.
>

I'm failing to come up with any good arguments in support of such a
posture.

If you make an assignment to a field and save the record, the assignment
should stick. Nothing else makes sense from a DBMS perspective. That's
exactly the sort of behavior that should be absolute and unquestionable.
(The only exception being that you have to be in a position to write any
changes to the record.)

I hope that they come in off the ledge and don't create a buggy feature
that will lead to some really, really hard to detect bugs in the field for
years to come.
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list
On Tue, Oct 31, 2017 at 8:21 AM, Alberto Bachler via 4D_Tech <
[hidden email]> wrote:

Just a quick note of thanks for posting this behavior to the list.

On Tue, Oct 31, 2017 at 3:49 PM, John Baughman via 4D_Tech <
[hidden email]> wrote:

...and to you too John for posting that you also got an official response.
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Chip,

Record 0 is the first record in the table.

Of course it may have been deleted and the number not reallocated.

Regards,

Wayne
Sent from my iPhone

> On 31 Oct 2017, at 15:03, Chip Scheide via 4D_Tech <[hidden email]> wrote:
>
> Alberto,
> doesn't Goto REcord ([table];0) - generate an error?
> there is no record number 0
>
> from documentation :
> If record is less than the smallest record number in the database or greater than the greatest record number in the database
>
>
>> Hello,
>>
>> If the value of a property is modified using object notation directly
>> over an object field the modified value is not stored on the record.
>> This is reproducible in v16R4 and v16R5.
>>
>>
>> READ WRITE([Table1])
>> GOTO RECORD([Table1];0)  // [Table1]Object.value is False
>> $b_value:=True
>> [Table1]Object.value:=$b_value
>> SAVE RECORD([Table1])  // [Table1]Object.value is True after Save Record
>> UNLOAD RECORD([Table1])
>> GOTO RECORD([Table1];0)  // after changing the current selection by
>> reloading the record [Table1]Object.value is false
>>
>> I reported this to 4D via TAOW and the Forum.
>> 4D answer was that is as standard behavior and they recommend me to
>> assign the object field to itself after modification.
>>
>> You can also use OB SET or assign the object to a variable and work
>> with it before reassign it to the object field.
>>
>> Alberto.
>>
>>
>>
>> **********************************************************************
>> 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:[hidden email]
>> **********************************************************************
> ------------
> Hell is other people
>     Jean-Paul Sartre
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list

> Le 31 oct. 2017 à 05:03, Chip Scheide via 4D_Tech <[hidden email]> a écrit :
>
> Alberto,
> doesn't Goto REcord ([table];0) - generate an error?
> there is no record number 0

Hi Chip,
"physical" record numbers start from zero, see here:
<http://doc.4d.com/4Dv16R4/4D/16-R4/BOOLEAN-ARRAY-FROM-SET.301-3317261.en.html>
"If N is the number of records in the table, element 0 of the array corresponds to record number 0, element 1 of the array corresponds to record number 1, etc."
In the same way, all records+longint array from selection --> array{0} is 0 and is a record number.

Alberto,
I'd call that a standard bughaviour.

--
Arnaud de Montard



**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list

>
> The problem is that the dirty flag is not set when dot notation is
> used against an object field. In your scenario the following will work
> …
.... field modified = field modified --right?!?!
 
> 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.
see above
------------
Hell is other people
     Jean-Paul Sartre
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list


> On Oct 31, 2017, at 1:53 AM, Chip Scheide via 4D_Tech <[hidden email]> wrote:
>
> .... field modified = field modified --right?!?!

You bring up a very interesting point. I thought the answer was No it did not have to be modified. but after testing I discovered, however, that while you a field saved to itself does not have to be modified to set the dirty flag, you must specifically  save an object field that was modified using dot notation to itself in order make it stick even if the dirty flag is otherwise set by another field modification. My observations…

ALL RECORDS([Patient Record])
[Patient Record]Test.testing:=“NewTest”
SAVE RECORD([Patient Record])
//NOTE:  Testing = “test” before, and remains “test” after the save. The table trigger did not fire.

ALL RECORDS([Patient Record])
[Patient Record]Test.testing:=“NewTest”
[Patient Record]Test:= Patient Record]Test
SAVE RECORD([Patient Record])
//NOTE: The table trigger fired and the object was updated. Yeah!

ALL RECORDS([Patient Record])
[Patient Record] Test.testing:=“NewTest”
[Patient Record]Comment:=“Comment”
SAVE RECORD([Patient Record])
//NOTE: The table trigger fired and the comment field WAS updated. But the object field WAS NOT updated. BOOO!

ALL RECORDS([Patient Record])
[Patient Record] Test.testing:=“NewTest”
[Patient Record]Comment:=“Comment”
[Patient Record]Test:= Patient Record]Test
SAVE RECORD([Patient Record])
//NOTE: BOTH fields were updated and the trigger fired,

I think that this tells me that the dirty flag explanation is BS. It is simply a bug in field dot notation. In the 3rd test the record was certainly set to dirty and the record was in fact saved as updated exept for the object field did not update.

I just this morning received the following with regard to the bug report that I filed months ago about this...

----------
Subj: [137286] Modifying c_object field with dot notation does not work as expected

Sorry for the bad news!

It looks like this bug ACI0097454 was marked as Standard Behavior on October 24th.

If you would like to see the standard behavior changed then you could file a feature request on the Forums. I think that may be a great idea because it will, at the very least, raise awareness to this behavior.
—————
 
I will try to follow up on this when I can find a bit of time to pursue further.

John



John Baughman
Kailua, Hawaii
(808) 262-0328
[hidden email]





**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
THIS is definitely a bug.

Past behavior is if a field is modified (even assigning itself to
itself) sets the 'dirty' flag, and the ENTIRE record is to be saved.


On Tue, 31 Oct 2017 09:58:09 -1000, John Baughman via 4D_Tech wrote:
>
> ALL RECORDS([Patient Record])
> [Patient Record] Test.testing:=“NewTest”
> [Patient Record]Comment:=“Comment”
> SAVE RECORD([Patient Record])
> //NOTE: The table trigger fired and the comment field WAS updated.
> But the object field WAS NOT updated. BOOO!
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list
> It looks like this bug ACI0097454 was marked as Standard Behavior on
October 24th.

Smells like a bug.
Looks like a bug.
Sounds like a bug.
Walks like a bug.

I mean, if you have a light switch that gives you a shock every time you
touch it, you wouldn't say "Oh, it always does that. It's standard
behavior." I mean, that's an accurate description (ouch!), but it's not a
reasonable reaction.
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
It must be a duck, cause calling this standard behavior is quackers. There
are many issues with object fields. I for one refuse to use them (Yes I
know how powerful they are and can be) as I do so much with sql and can not
get them using a sql statement.  I have commented before that 4D should not
implement a ew data type for a field unless they also update sql in some
way to accommodate it.

It would or examples be strange it they added a pony type fields like SQL
already has and did not support the same.

In fact there UUID implementation is strange as well. How do you tell if
the field is a UUID - type = alpha and length = 0, when you get field
properties

Regards

Chuck

On Tue, Oct 31, 2017 at 4:09 PM, David Adams via 4D_Tech <
[hidden email]> wrote:

> > It looks like this bug ACI0097454 was marked as Standard Behavior on
> October 24th.
>
> Smells like a bug.
> Looks like a bug.
> Sounds like a bug.
> Walks like a bug.
>
> I mean, if you have a light switch that gives you a shock every time you
> touch it, you wouldn't say "Oh, it always does that. It's standard
> behavior." I mean, that's an accurate description (ouch!), but it's not a
> reasonable reaction.
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
>



--
-----------------------------------------------------------------------------------------
 Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
 Informed Solutions, Inc.
 Brookline, MA 02446 USA Registered 4D Developer
       Providers of 4D, Sybase & SQL Server connectivity
          http://www.informed-solutions.com
-----------------------------------------------------------------------------------------
This message and any attached documents contain information which may be
confidential, subject to privilege or exempt from disclosure under
applicable law.  These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution, disclosure,
printing, copying, storage, modification or the taking of any action in
reliance upon this transmission is strictly prohibited.  Delivery of this
message to any person other than the intended recipient shall not
compromise or waive such confidentiality, privilege or exemption
from disclosure as to this communication.
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
I’m glad I came in today.


> On Oct 31, 2017, at 1:35 PM, Charles Miller via 4D_Tech <[hidden email]> wrote:
>
> It must be a duck, cause calling this standard behavior is quackers.

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list
In reply to this post by 4D Tech mailing list
➢ And, yes, I too was told that the engineers were leaning to declaring this as standard behavior. Why? I have not a clue.


**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: [Warning] Settings properties values on object field by object notation

4D Tech mailing list


On 11/1/17, 2:08 PM, "4D_Tech on behalf of Tom Swenson via 4D_Tech" <[hidden email] on behalf of [hidden email]> wrote:

    ➢ And, yes, I too was told that the engineers were leaning to declaring this as standard behavior. Why? I have not a clue.
   
    Ooops, I was just going to chime that it was probably easier to declare it as default behavior rather than “fix” it.

**********************************************************************
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:[hidden email]
**********************************************************************