setting element modified date in code

[OpenIT Solutions]

Hi,

I can see this was discussed sometime ago, but not clear/sure on answer.

I want to use VB to set the modified date of an element. I can see from the API docs thats its a read/write attribute.

So i set the modified date: and execute the update method. Nothing happens.

myElement.Modified = DateTime.Now
myElement.Update

? Other than Geerts previous suggestion of calling Repository.Execute(SQLString) can anyone suggest another option ? Is this a known bug ? Am i being stupid ?

Why do i want to call this - because i want to change the elements modified date if i modify the value of an associated and existing tagged value.  

[qwerty]

Just tried it here with 9.3. Same effect: date/time does not change. Date/time for a bug report?

q.

[Eve]

I don't think you can really assign a value to Element.Modified. It's automatically set when an element is saved if there are changes. That behavior is consistent with the automation interface. That means that you can't force it to write any value other than now, and you can only make that write by setting another property.

[qwerty]

Wrong. The help says Read/Write.

q.

[Eve]

I provided an explanation for the current behavior. I did not say that the help and EA are consistent or provide any opinion on how it "should" behave.

Do you care to define what you think is "wrong"?

[RIL]

Seriously, salesmen don't argue over stuff like this.

Of course there's something "wrong", and anyone can clearly see exactly what is wrong - the discrepancy between your explanation and the help file.

Fix it, or at least don't argue.

You are not doing the company any favor with that attitude. People are really helpful here. Encourage them instead. And yes, I think you have been helpful too. But with a sour taste.

WHY Simon?

// Rolf Lampa
(real name)

[qwerty]

Fully agree to what Rolf said.

Simon, the documentation is what counts. If the implementation does not do what the docu tells, the implementation is wrong. Of course you're free to adapt the docu so it is consistent with the implementation. But right now they diverge.

BTW: Your argumentation is "logical". Just put it in the docu and that it is.

q.

[edit] I think that it should be possible to force an update of the modification time for the reason mention above. When I call update in the current implementation it only updates the modification date if there's a change. So the only way around to change the name to something different and then change it back.

[OpenIT Solutions]

I'm not sure the argument is logical - check out my orginal post and why i need to set the modified date manually - i tagged value of an element has changed - to me the element has changed - in an ideal world the modified date of the underlying element should change automatically - it doesn't - so i need a way to manually change it.

As a work around i can do as geert suggestions or i've found that i can clear / update / reset / update an atribute of the element to force a change to the modified date.

My preference here would be that if you change any attribute (and a tagged value from an automation interface perspective is an attribute) of an element its modified date should be set....

[qwerty]

The same would go for attributes/methods which also do not touch the modification date of the according class.

q.

[g.makulik]

After all that discussion about "logical" behavior of this property:

IMHO instead of making it writable (where read only is very probably correctly intended) there should be either

• an extra method to update it with the current date/time
• or the existing Update() methods should do this transparently no matter if anything has changed or not.
  

The latter could also be decorated with an extra optional parameter (e.g. bool force = false).

Just my 0.02 EUR
Günther

[Eve]

I'm sorry if I caused offense.

I take the time to contribute to this forum because I care about EA and personally want the best experience for its users. Not because my job requires me to do it. I'm not a salesman, I'd make a really bad one and I'm often not a diplomatic person.

I stated some facts about how it was working and was told I was wrong. That's okay. I'll just state some more facts.

• The documentation states "Read/Write" for a property if you can set that property from code. It states "Read only" if you can't set the property.
• The behavior of these isn't always what you would expect. Element.Attributes is read only, but you can modify the collection. Just not replace it.
• Element.Modified (and likely Element.Created) being marked as Read/Write only that your compiler will allow you to set it.
• For exactly that reason I don't think it will ever be changed. We don't make changes that will prevent your existing code from compiling (or worse cause crashes because it linked to something that no longer exists) just because it's being compiled against/run on a new version of EA.

Given those points, Sparx Systems has a number of choices.
1. Allow writing it. (If my memory serves correctly we've had this request and said no.) This would also bring up the possibility of changing behavior in users add-ins.
2. Lie about it in the help and call it read only.
3. Put a note somewhere that states that values written to the property will be ignored.

[g.makulik]

I'm sorry if I caused offense.

Not really Simon! Some people seem to over-react here as soon they see answers from sparx emploees.

3. Put a note somewhere that states that values written to the property will be ignored.

That's all what likely needs to be stated in the docs.

Let's go on about discussing a reasonable solution for the OP's original problem.

Best regards,
Günther

[qwerty]

I just join Günthers statement.

From my point of view an additional method UpdateModification would be the best solution.

q.