I think it's really important that you find out why the tool is written to start a transaction before every query.

The three techniques for using SQL in your code (Class queries, Dynamic SQL, Embedded SQL) each have their pros and cons. The %ObjectSelectMode and tResult.<column> (instead of tResult.%Get("<column>") ) features only work with Dynamic SQL.

Thanks Mihoko!

Also note: the argument with ... after its name doesn't have to be the only argument to the method; it must be the last argument to the method. So NewMethod1()'s signature could be:
​​​​

ClassMethod NewMethod1(a as %String, b as %String, c... as %String)
{
    kill ^a, ^b, ^c
    set ^a = a, ^b = b
    merge ^c = c
}

Running it like this:

USER>DO ##class(TEST.ARGTEST1).NewMethod1(1,2,3,4,5,6,7)
USER>ZWRITE ^a, ^b, ^c
^a=1
^b=2
^c=5
^c(1)=3
^c(2)=4
^c(3)=5
^c(4)=6
^c(5)=7

So...if Person #1 in the above example references demo.intersystems.Car #54, the "Dan P big secretly loaded" copy of that Person object also references the same Car #54, right? @Timothy Leavitt, is that good or bad for your use case? Doesn't %ConstructClone(1) give you what you need? If not, where does it fall short?
 

I think it would be great if you would explain the use case to the community.

• Why do you need to do your own property-by-property validation separate from %ValidateObject()
• Why are you using "m%"_Property and not just Property?
• Why can't you use the built-in propertyIsModified() method to verify if a property is modified?

After reading through this thread, it seems like there are two questions:

1. What is the correct syntax for calling a method? That question has been answered by several posts. It's either using ..method2() if method2() is in the same class as method1(), or ##class(package.class).method2() if method2() is in a different package.class. Use "do" to call the method, or "set retval = " to call the method and capture the returned value.
2. Why when I run method1() I get data, but when I add a call to method2() from inside method1() I get no data? As Davide suggested, using "adm" as an embedded SQL cursor in the GetDataExecute() method and the GetSphereJauh() method is probably causing the problem, so try changing the cursor name to "juah" in the declare, open, fetch and close statements in GetSphereJauh(). If that doesn't help, you should probably contact TrakCare Support and get their help.

Would it be possible for you to share your reason for wanting to do this with the community?

In VS Code, you can use snippets for that.

Anything can be achieved without instance methods. The point here is that instance methods exist in object-oriented systems because they are considered a good, straightforward way to achieve certain things. In the case of unit tests sharing information using properties, that approach saves you from having to pass info around as method arguments, or declaring a list of public variables.

I've also used Studio for 20+ years. I can still remember how much better it was than what we had before. We can all still use Studio if we want; it's not a forced divorce. But we hope that VS Code -- ObjectScript's features will make you comfortable enough to decide to do a conscious uncoupling. And as Frank Sinatra sang: "Love's much lovelier, the second time around." And he could have sung that at the Diplomat Hotel in Fort Lauderdale in 1974, where coincidentally InterSystems is hosting our Global Summit this year!

In the interest of accuracy, Studio does allow looking at OREFS to see their properties (View As > Object, or Dump object).

Why are unit test methods instance methods? Since a running unit test is an instantiated object (%RegisteredObject), the unit test class itself can have custom properties, and the instance methods can use those properties as a way to share information. For example, initialize the properties in %OnBeforeAllTests(), and then access/change the properties in the test methods. 

LAST_IDENTITY() returns the ID of the last record inserted, updated, or deleted. This is very useful from ODBC/JDBC. From within an ObjectScript method, you can access this directly instead of running an additional SELECT statement:

• For Embedded SQL, you can use the %ROWID variable.
• For Dynamic SQL, you can use the resultset.%ROWID property.

^rMAC("your routine")

@Nicholai Mitchko's example above is Python calling an ObjectScript method that has pass-by-ref arguments, and that works as he described. I wondered if Python methods could be written to return values in their arguments, despite the fact that Python doesn't have pass-by-ref arguments. The answer is "yes," but only if the caller passes in a data structure (like a list or a dict) that the Python method modifies. Otherwise, arguments to a Python method called from either ObjectScript or Python can't return values.

If you make a loooonnnnng $piece-delimited string, and a lonnnnnnnnng $list, and you loop 1000000 times, accessing random pieces and random $list items, and sum up the time, and divide by 1000000, you'll find that for access, $lists are faster than delimited strings. At least that's what I saw when $list first appeared. But my mentor from that time said "Yes Joel, they are faster, but $list was added to ObjectScript so that we wouldn't have to worry anymore about delimiters, and sub-delimiters, and sub-sub-delimiters, etc."

True. I personally am not a fan of using #dim in any way other than:

#dim variable as objectclassname

because it makes it clear that #dim provides code completion for object variables, which is the functionality I care about. Yes, I know it also provides variable documentation for developers who are used to declaring datatypes in other languages

The other documented options:

• #dim variable as objectclassname = initialvalue (ok, but I prefer #dim followed by set)
• #dim variable = initialvalue (there's no reason to use #dim to do what set does)
• #dim variable as non-objectclassname (this is documentation only; no code completion is provided)
• #dim variable as list/array of objectclassname (again, documentation only; no code completion)