Hi Aaron,

This is a method inside Class %Library.GlobalIdentifier.

I realize it says in the comments: "The return value will only differ from the supplied value if the override is unsuccessful." - however in my testing, this is not the case.   You can put anything invalid in there - like the word "test", which is not valid GUID.  It will not replace the GUID with this invalid string, but it will not return the error message either.  You can also put non -unique GUID, which also will fail replacing (as it should), but will not return the error message. 

hi Jean,

Thank you, but the thing is - next time when you run this (just part 2) - it will also not find it the first time.  In other words, I believe index has been built correctly, something else is going on.

Thanks,

Alex

Hello Mark,

Thank you, that is great, I will upgrade to 2017.1

Alex

Thank you Tim, will give it a try.

Thank you everybody for your answers. My question here would be, why use class method instead of regular method in this case? 

If you don't want it to have exposure to outside world, simply make it a regular method within your class, which is going to be private (I believe) by default and use as many as you need privately, while still have an outside entry point if needed with non private class method.

I guess what would be the benefit to use class method vs regular method here?  

I see myself small benefit to make something originally class method [private] vs regular method - in case in some point in the future of your application, you need to change the ability to get to the method from the outside and remove the private tag.   

I meant - I guess what would be the benefit to use class method [private] vs regular method [private] here?  

Thank you, I think I understand now the differences well, but benefits is still a little odd.  Is there a difference / benefit / correct preference between using regular method() [private[ vs classmethod [private]?  If for example you are looking to keep your methods private.

Thank you Robert.

That worked, and thank you very much for the explanation.  I would not guess something like this.  Great to know,

Alex

Thank you, I think that will work.  Adding a label does not seem to interfere with routine flow, so at least you can run a unit test starting from anywhere, but you still will have to run the routine to the end.

Either way, this is definitely an option if you wish to run a unit test from some point other the starting label.

Thank you,

Alex

Thank you Ben.  I realize there maybe an issue there.  I was thinking someone came up with a workaround (sort of speaking).  In either cases, I think labels would work well to test partial huge routines, but it will only alter the starting point, not end.  

Thank you Robert.  

Thank you for clarifying, that is what I ended up doing.   

Thank you, that makes perfect sense.

Thanks Tim, that works. 

Thank you Robert

I like the GetStored answer, which would work perfect in my case to make certain the child is stored properly.  

In my real life example, the original save used %Save(0) and therefore did not save somethingelse.myNewProperty, but it was still displaying the correct value when I was (ref it directly) and writing it out, as it was getting it from memory.

I thought so too, but it clearly does not work. Maybe it's a bug in TROLLBACK.

my exact steps to reproduce:

1.Open up terminal session. 

2.> TSTART

3. Set any simple global to test: S ^AKTEST=123

4. Disconnect VPN

5. Reconnect VPN

6. Open up new Terminal Session

7. Look up that global - It is still there with my setting.