How does it connect - via ODBC/JDBC or is there another connection mechanism?

There is no such command.  I would recommend moving the index global as well.  However, if this is not an option then you probably want to do something like:

USER>s sql="select Name from %Dictionary.CompiledClass where system=0 and NOT(Name %Startswith '%') AND SUPER [ 'Persistent'"     


USER>s rs=##class(%SQL.Statement).%ExecDirect(,sql)                                                                               

USER>while rs.%Next() { s sc= $classmethod(rs.%GetData(1),"%BuildIndices") w "Built "_rs.%GetData(1)_" with return code = "_sc,! }

Obviously this is kind of hacked together and you'll want to clean it up, but the outline is there.  I had to make some assumptions like you don't have any other classes in your application that have 'Persistent' in them.  If you do then you'll want (Super [ '%Library.Persistent' OR Super [ '%Persistent').  Since classes are case sensitive this should be fine. 

Triggers are fired after data normalization and validation.  Do you think you can/should use your own datatypes, overriding the Normalize or LogicalToDisplay/DisplayToLogical functions.  If that doesn't make sense you could have a field calculated off of the stored data?  There are lots of options here, the best one is going to depend strongly on the goals you have for the project.

These answers are all sufficient.  However, perhaps a more natural solution is to make the field of type %Date.  Then you can use the SelectMode to determine how the date is represented in a query.  For instance, look at the DOB field in Sample.Person (in the SAMPLES) namespace.  The storage looks like this:

^Sample.PersonD(1)=$lb(","Waterman,Brenda Z.","437-96-2023",36088,...)

Here we see the ID (1) the Name ("Waterman,Brenda Z.") the SSN (437-96-2023), and the DOB (36088).  If you want to see the data you can do the following:

--------------------------------------------------------------

SELECT Name,DOB FROM Sample.Person WHERE ID=1

Name                                     DOB

Waterman,Brenda Z.      36088

--------------------------------------------------------------

If we wanted to see that in a readable format, we can change the selectmode and get:

--------------------------------------------------------------

Name                                       DOB

Waterman,Brenda Z.   1939-10-22

--------------------------------------------------------------

Moreover, you can use this in the WHERE clause very naturally:

--------------------------------------------------------------

SELECT Name,DOB FROM Sample.Person WHERE DOB='1939-10-22'

Name                                           DOB

Waterman,Brenda Z.     1939-10-22

Underman,Jane V.          1939-10-22

Bush,Susan E.                   1939-10-22

--------------------------------------------------------------

The way to change the selectmode is going to depend on how you are running your query.  All queries that come through xDBC are in ODBC mode, so that's easy.  If you are running a dynamic SQL statement you can do:

s stmt.%SelectMode=1  

Possible values are:

• 0 for LOGICAL mode.
• 1 for ODBC mode.
• 2 for DISPLAY mode.

If you are using embedded SQL, you can use the precompiler directive #SQLCompile select=<value> as outlined here:

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

SIMPLEST?  %String, definitely.  You can even use the ['whatsup@doc.com' syntax to search if you have to.  Using List of %String is a messy way to do anything in the relational world.  

If you do need to index them later, I'm pretty sure you can use iFind to do this without too much trouble (although you would need a new license, potentially).

Cache 2010.2 does not support Java 7:

http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?...

You'll need to use an older version of Java or a newer version of Caché.

Note: Java 7 was released in July 2011, so obviously we couldn't support it a year before its release.

P.S. Sorry it took you so long to get an answer!  If ever you need something more quickly, please feel free to contact the WRC at support@intersystems.com.  

Example!

Class:

------------------------------------------

Class Jiri.RegisteredObject extends %RegisteredObject {

Property p1;

Property p2;

}

------------------------------------------

Terminal:

------------------------------------------

SAMPLES>s j=##class(Jiri.RegisteredObject).%New()

SAMPLES>s j.p1="test"

SAMPLES>s j.p2="json"

SAMPLES>w ##class(%ZEN.Auxiliary.jsonProvider).%WriteJSONStreamFromObject(.stream,j)

1

SAMPLES>w stream.Read()

{

"_class":"Jiri.RegisteredObject",

"p1":"test",

"p2":"json"

}

------------------------------------------

Do your CSP Files show up in the Server Explorer portion of Atelier?  Also, what is your Atelier version (Atelier->About Atelier)?

P.S. I think that was the most I've ever written "Atelier" in a short time.

Caché does NOT support SQL-92 in its full implementation, so please refrain from saying so.  Example:

SELECT 3+3*3

Result: 18

Clearly, by not following order of operations we are violating the standard.  Moreover, despite not conforming perfectly to SQL-92 we do support plenty of extensions, such as Table-Valued Functions.

That said, Caché does not support WITH in the way you describe.  However, you can accomplish the same thing by using subqueries, VIEWs, or multiple queries.  You can also JOIN each record with its parent and filter on that.  If you give some more information I'd be happy to point you in the right direction.

Sure - you can try to merge it off before deleting it:

m ^KMB = ^%sqlcq("NSP","SMPQueryHistory")
 

And then you have your query history in a different global, which you can reference when needed.