BTW, these both changes are in 5.0 (BJB266 since 5.0.3, and DLP1138 since 5.0.7)
Regards, Timur Safin
On 12.05.2004 14:41, Wolf Koelling said the following:
Or possibly DLP1138 in 5.0.7? (http://www.intersystems.com/cache/technology/product-tables/releasenotes/50 7/index.html#DLP1138)
Wolf Koelling Slaughter and May
"John Murray" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
Sharon,
What Cache version?
Sounds like the issue fixed by BJB266 in 4.1.16. See http://www.intersystems.com/cache/technology/product-tables/releasenotes /4116/index.html
John Murray George James Software
-----Original Message----- From: Sharon Hershon [mailto:[EMAIL PROTECTED] Posted At: 11 May 2004 08:25 Posted To: intersystems.public.cache Conversation: %IsModified and relationships Subject: %IsModified and relationships
I'm curious as to folks take on this. I have class named Site that has a one to many relationship to a class named Records (so one site has many records). The following code causes the %IsModified flag to go to 1:
w oRec.%IsModified() 0 w oRec.recToSite.internalNo // Relationship recToSite As Core.Site [
Cardinality = parent, Inverse = siteToRec ];
0 w oRec.%IsModified() 1
To get the value of oRec.recToSite.internalNo site needs to be swizzled, but that causes oRec's modified flag to go to 1. What I really want is to rely on IsModified for when properties actually change value on oRec. It could be argued that a relationship property has changed value, thus %IsModified is true, but I sure wish I could take relationships being swizzled out of the picture.
Has anyone been down this road? Do I have to roll my own here?
MTIA,
/Sharon
