(It's probably obvious, but if you want an accurate value on or around the actual birthday, then it's a lot more complex than dividing by 365.25. You have to go down to splitting and comparing months and days, especially in a leap year.)

Hello. I'm afraid objectscript does not have the exact equivalent of the Java/C# LOCK command.
As far as re-entrant in the same process goes: there is no need, as objectscript has no ability to parallel process in one process. It's a "simple", interpreted language with effectively one thread (though the interpreter itself is another matter).

What is worse (maybe) is the way programmers prevent problems with concurrency is "by convention only". Our lock command puts entries in a shared "lock table", and that is then available for other processors to read to see if something else is using it. But it can be ignored, unlike in Java. See  https://docs.intersystems.com/iris20251/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_lockbasics#GCOS_lockbasics_uses_activity_blocking

(By the way, I personally think there's no need to use "device opening" these days as modern systems usually make a good job of cleaning up the lock table when something goes wrong.)

Hi everyone,

That stored procedure solution looks great, and may work, but I'd just like to point out that you have no control over what order the rows are in when the method is called. That's going to be decided by the compiler.

If you've done "ORDER BY Date DESC" then it could build a temporary index by date and then run through that to extract the output, so row 4 would be processed first and the call to the method will return "New" instead of "Old".

Putting in the required order in the query might work, but even then, you have no certainty what the compiler will do. You either need a subquery, or calculate the column outside of SQL when you pull the rows (in the right order).

Regards,

Mike