User bio

Developer on the Language Interoperability Team at InterSystems.

Member since Nov 7, 2015
Posts:
Replies:
Dan Pasco · Apr 10 go to post

I've edited portions of this to protect the innocent. The code I wrote to implement this does not make use of any secret internals - it is available to anyone. I chose two arrays - columns names and column values because we only need column names once. The code could easily produce rows as objects instead of arrays. My code accepts an SQL Result - not necessarily a result set - and produces a DAO (dynamic abstract object) from it. A result is returned by executing any SQL statement and it can contain multiple result sets, output-directed columns (not result columns), etc.
 

USER>set r = $system.SQL.Execute("select top 2 name,birthdate,age from person","odbc")
USER>set r = <something>.resultToDao($system.SQL.Execute("select top 2 name,birthdate,age from person","odbc"))
USER>:pp r
{
 "statementType": "SELECT",
 "sqlcode": 0,
 "metadata": {
   "columns": [
     {
       "name": "name",
       "precision": 50,
       "scale": 0,
       "type": "string"
     },
     {
       "name": "birthDate",
       "precision": 10,
       "scale": 0,
       "type": "datetime"
     },
     {
       "name": "age",
       "precision": 10,
       "scale": 0,
       "type": "number"
     }
   ]
 },
 "rows": [
   [
     "Dan",
     "1960-01-01",
     66
   ],
   [
     "Steve",
     "1959-12-01",
     66
   ]
 ],
 "rowcount": 2
}
SDK:USER>

No - IDENTITY is for both Objects/SQL. I don't know why the $system.OBJ function was refactored to place it into a SQL class but IdentityInsert is a feature we added quite some time ago to support either T/SQL or Informix. 
IDENTITY property/column is system assigned but can be explicitly set and the IDKEY is based on this property. This is the global produced by my "E2" test where I set the id property to 100.

^com.intersystems.AppD=102
^com.intersystems.AppD(100)=$lb("","E2")

I don't know anything about ALLOWIDENTITYINSERT - maybe someone has added that since I was last involved with the compiler? 
But - as a general rule - you should not allow IDENTITYINSERT all of the time as it introduces a responsibility to keep the ID counter updated. When I first ran my test, it failed not because identity insert didn't work but because my counter wasn't updated to be 101 (I had inserted 100 with ID set).

UPDATE:

I researched this and found that while the documentation implies that you can define this parameter in any persistent class, that isn't the truth. The documentation appears to be wrong. It only works for classes using SQL Storage. It won't work for your case. Unless I misread the source code changes. I did look at %Persistent and that parameter is not defined by that class.

Open Exchange applications:
Certifications & Credly badges:
Dan has no Certifications & Credly badges yet.
Followers:
Following: