Well, we now have two different platforms Caché and IRIS. With so many changes, that it makes so many difficulties to have the same sources for both platforms. I'm not arguing about the reasons for it. Some of the changes are really reasonable.
It's good when I can import code from Caché to IRIS and get it worked after all background job was done. In Caché we have %CacheStorage type used for Storages. In IRIS it automatically converts to %Storage.Persistent. So, If I develop on IRIS, I will have incompatible sources for Caché.
I stumbled across a comment in this post that mentioned that the %SYS.GlobalQuery is a potentially faster alternative to %GSIZE. I tested it out and while I like the %SYS.GlobalQuery I noticed that it has some size discrepancies against a %GSIZE with details. Can anyone tell me which is more accurate for estimating the size of globals?
I have a DR Mirror with a WIJ that is 5 times as large as the Primary Failover member. My Read-Write Reporting mirror WIJs are the same size as the Primary. I don't know why the DR WIJ i so large and would like to shrink it to the same size as the others. Any suggestions are welcome. Thanks!
In recent discussion on CachéQuality I was (friendly) blamed for old syntax promotion and deliberate obfuscation of the code. Therefore I decided to clarify my point and shed some light on one of possible source of side effects that may unexpectedly occur with RETURN command with an argument.
Hope most of you already familiar with project CachéQuality from @Daniel Tamajon. For those who don’t know about it, it is a static syntax analyzer for your code written for InterSystems products. It may help you to find and solve many different types of issues in your code, and even possible bugs before clients will find it in production. So, with help of CachéQuality you will be able to deliver a better product. You can find the complete list of rules used to check ObjectScript code here.
It was already available in Studio. And now it is also available in VSCode.