It depends on table definition. If you define your table with a PK that is not auto-increment (default) then you sure can pass your own ID. 

You can assign your own ID: CREATE TABLE mytable (field1 INT PRIMARY KEY, field2 VARCHAR2)

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Try looking at this https://github.com/intersystems-community/iris-driver-distribution

Even though the driver is listed in maven repos it doesn't download. You need to [manually] include the library in your project.

Can you show the query plan? Usually this issue "shows" when indices are out of sync. Maybe try rebuilding indices.

The list of steps depend on how is your current application built (e.g. are you using direct global access vs. SQL). Depending on which direction you want to go you could simply wrap your existing objectscript code in either stored procs or services and access them from Java or rewrite all your existing logic in Java.

Again, the steps would depend on what exactly you're trying to accomplish and your current app makings.

The "||" is used to concatenate. So that's why it makes sense those are the ones used in the SQL you pasted instead of "!!".

The error should be in the %objlasterror variable. You would have to check: if %New() returned a new instance, if not then check the value of %objlasterror. Then perform any error handling you'd like to do. 

try/catch doesn't work because %New() doesn't throw any exceptions.

It's hard to tell what's wrong without all (or more) details. Are you getting an error? If you're not getting an error, are you passing the correct values (values that should return records)? Also, have you tried creating a very basic stored proc in Oracle (select current_date from dual or something like that) and try to use that from IRIS? The exercise will help you eliminate variables for possible issues.

You can map an Oracle Stored procedure to IRIS method using the SQL Gateway. Once the mapping is done, you can expose it with a service or any other means IRIS provides.

To add a new header, you need to create a subclass of  %SOAP.Header with the property you need. Once you have that then you can add it to the appropriate array e.g.

S myheader = ##class(MyNewHeader).%New()

S myheader.mykeyproperty = <myvalue>

D myservice.HeadersOut.SetAt(myheader,"MyNewHeader")

This is assuming the header is not automatically generated from the XML schema.

Since you're using ObjectScript you should get the value from the list using something like $LISTGET(CList,i). That should return the correct value without control chars. 

If you still want to use $PIECE then SET CListString = $LISTTOSTRING(CList) and then use the $PIECE on the CListString

The default value for connection pool size on boot is usually 10. You may want to set this value to 1 or 2 for testing purposes (if using the IRIS community version).

The confusion here is that you created 3 class mappings for a single global (not a good practice) and your understanding is that they're just "views", however the 3 of them are full class/tables with the same properties/ownership of the data. With that in mind, using SQL DROP statement has the same effect for any of the 3 tables/classes  (if DDL were allowed).  As others have pointed out, you can accomplish what you're trying to do with DROP %NODELDATA or by removing the class definition (either from Studio or programatically). 

If you wanted to declare views instead of tables then you need to do so via SQL CREATE VIEW statement.

You can remove the Calculated keyword and use a combination of  SqlComputeOnChange and Readonly keywords.

What you accomplish:

- Removing Calculated keyword, makes the column persistent

- Adding SqlComputeOnChange gives you control on when you want the value to be calculated (using %%INSERT or %%UPDATE) and based on which column (don't add any if calc must happen for all inserts regardless of which fields are being inserted).

- Adding Readonly just provides and extra "safety" that the value can't be changed via SQL or Object means.

 Property readonlyprop As %String [ ReadOnly, SqlComputeCode = { S {*} = {ID}_(+$H)}, SqlComputed, SqlComputeOnChange = %%INSERT ];

Agree on your "usefulness" statement. Making a class non-extendable breaks all recommended development practices. For example TDD. I won't be able to mock this class for testing purposes and will be forced to test with your class only (Granted Cache is not strong typed so in theory I have ways to bypass this limitation but still). 

Another recommended principal is to use composition instead of inheritance so in theory I could do exactly the same I wanted to do with your class (after you "lock it down") by making it part of another class without extending it. If a developer wants to get around your class ( don't know the reasons why) he/she can by other means unless you plague your code with a bunch of type checks (making Cache strong typed). 

Even if a developer get to extending your class, the fact you can't overload methods in Cache gives you a level of restriction when combined with deployed code and final as there's "no way" a developer can change your implementation so your code will still call your methods' implementation on a subclass.

All and all it seems you're going to extremes for no real benefit but since we don't know the whole picture maybe this effort is worth it. 

It can be "both"

$zt = $ztrap (documentation)

$zt(<time>,.....) = $ztime(documentation)

1) The reasons for using both together are purely based on your application's need and design. Some design patterns specify desired visibility of methods for example.

2) Safe depends on the context but it's usually easier to move from a restricted mode to a non-restricted one. Moving methods from private to public shouldn't have any impact on your application (functionality wise). However, the opposite is not true and will require you to modify your code to fix the parts that were accessing previously public methods that are private now. This will also impact clients of your code (API) as they'll face the same challenges with the new restrictions.

Relationships load a "collection" of pointers to the members of the relationship. Objects are loaded to memory only when accessed. Pretty much how Arrays work as well. In essence Arrays and Relationships work the same. Relationships provide the extra referential integrity.

Parameters being passed to a SOAP operation are also defined as properties in the generated class. In your override method, the "proxy" parameter will have a property matching the name of Obj1 and Obj2 parameters. Given your example the following should work

Method override(proxy As %SOAP.ProxyDescriptor, tag As %String)

{

             ....

            W proxy.Obj1,!

             W proxy.Obj2,!

            ........

}

Out of curiosity, why would you need to have a calculated field for this setup? You can always access the properties on ClassC with the following query

SELECT BRecord->Record->Propx FROM SQLUser.ClassC