ir a la publicación Jose Tomas Salvador · 31 mayo, 2021 Una de las opciones - No usar el namespace USER. Por qué preocuparnos de lidiar con USER? Una opción más productiva y limpia es crear tu propia base y namespace desde cero. Eso es por lo que creamos una nueva base de datos y namespace IRISAPP en cada plantailla, por ejemplo: las plantillas objectscript, rest o ZPM package. Con esta aproximación del tipo infrastructure-as-a-code, sabes con seguridad que namespaces, mapeos, seguridad, bases de datos, usuarios, ... utilizas y cómo se configuran, porque son los que creas tu. En todo caso, en instalaciones iniciales de InterSystems IRIS, al menos desde la versión 2020.1, el namespace USER no viene configurado por defecto con la opción de interoperabilidad activada.
ir a la publicación Jose Tomas Salvador · 22 abr, 2021 La sentencia tiene un error sintáctico, constraint debe ir precedido por una coma. Por otro lado, si lo que se quiere es tener un identificador de fila autoincremental creciente, basta con no indicar la columna ID (y por tanto eliminar la constraint por innecesaria), ya que IRIS creará por defecto una columna ID que mantendrá un valor único numérico creciente por cada nueva fila. Quedaría: CREATE TABLE SQLUser.Teste (coluna1 VARCHAR (255), coluna2 VARCHAR (255), coluna3 VARCHAR (255), coluna4 VARCHAR (255)) En este caso no tendríamos Primary Key, tendríamos sólo un IDKEY, proyectado en SQL como la columna ID, cuyos valores identifican unívocamente cada fila. Si lo que queremos es tener una primary key que podamos insertar explícitamente nosotros, pues esa sentencia valdría, añadiendo la coma que falta claro: CREATE TABLE SQLUser.Teste (ID INT NOT NULL, coluna1 VARCHAR (255), coluna2 VARCHAR (255), coluna3 VARCHAR (255), coluna4 VARCHAR (255), CONSTRAINT TestePK PRIMARY KEY (ID)) En ese caso, al existir ya una columna con nombre ID, IRIS generaría una columna de nombre ID1 donde igualmente nos daría un valor numérico creciente único por fila. Este ID1 sería el IDKEY (no confundir con Primary Key) e ID la Primary Key. Si quisiéramos tener una Primary Key que coincidiera con el IDKEY, haríamos: CREATE TABLE SQLUser.Teste (ID INT IDENTITY, coluna1 VARCHAR (255), coluna2 VARCHAR (255), coluna3 VARCHAR (255), coluna4 VARCHAR (255), CONSTRAINT TestePK PRIMARY KEY (ID))
ir a la publicación Jose Tomas Salvador · 15 abr, 2021 @Julius Kavay ha dado una muy buena alternativa. En lugar de insertar debug_macros, prueba la utilidad TRACE de Intersystems. write $$DIR^TRACE("c:\Temp\") ; to set an output directory write $$ON^TRACE(jobnr) ; the pid of the process you want to trace ; zn "appNamespace" ; do ^yourProgram ; zn "%SYS" write $$OFF^TRACE(jobnr) ; to stopp the trace do ^TRACE ; to display the trace result TRACE muestras las llamadas a métodos/funciones con argumentos. Para hacer uso de ella, debéis de estar en el namespace %SYS... o podéis mapearla al namespace %ALL y así la podréis utilizar desde cualquier sitio. No aparece actualmente en la documentación oficial, pero podéis encontrar información de uso ejecutando do ^TRACE y en la propia rutina ^TRACE.int (podéis ver el código fuente completo desde el portal, el Studio, VS Code,...)
ir a la publicación Jose Tomas Salvador · 15 abr, 2021 Creo que esto va a ser muy útil para los usuarios actuales de ZEN que quieren evolucionar sus front-end!! 👍
ir a la publicación Jose Tomas Salvador · 11 feb, 2021 Hola! ¡El período de registro ya ha comenzado! Sigue nuestro Tablón del concurso y estate atento. Aguardando esos proyectos increibles! :-)
ir a la publicación Jose Tomas Salvador · 11 feb, 2021 Gracias a ti por estas contribuciones. Me gustó mucho tu idea.
ir a la publicación Jose Tomas Salvador · 14 ene, 2021 Hola Mathew, Sí. Si hay un error interno en alguna de las llamadas que hace para localizar la tabla y hacer el purgado, el error podría aparecer en $ZERROR. No obstante, hay varias llamadas a métodos internos... no me ha parecido, pero alguno de ellos podría poner a "" el $ZERROR si gestiona el error y considera que debe ponerlo a null. He seguido la cadena de llamadas hasta 3 o 4 niveles y no he visto ningún set $ZE="" explícito... o sea que en principio, si hay algún error interno tras la llamada, $ZE o %objlasterror deberían tener algún valor.... OJO, esto no implica necesariamente que la operación de purgado haya fallado... algún metodo o rutina intermedia puede lanzar una excepción (lo que modificaría el $ZE), que a su vez podría ser gestionada por algún método/rutina del nivel superior sin mayor problema y sin afectar a la acción de purgado. No creo que sea así en este caso, pero podría ocurrir.
ir a la publicación Jose Tomas Salvador · 14 ene, 2021 Hola Mathew, ese método no devuelve ninguna información ni en caso de error ni de éxito... como bien dices, siempre retorna "". Una opción perfectamente válida para verificar (sugerida por Anderson Negrelli) sería usar: ##class(%Library.SQLCatalog).GetCachedQueryTableCount("table_name") Este comando devuelve el número de consultas cacheadas de una tabla y te permite comprobar si todas las consultas cacheadas se han purgado.
ese método no devuelve ninguna información ni en caso de error ni de éxito... como bien dices, siempre retorna "". Una opción perfectamente válida para verificar (sugerida por Anderson Negrelli) sería usar: ##class(%Library.SQLCatalog).GetCachedQueryTableCount("table_name") Este comando devuelve el número de consultas cacheadas de una tabla y te permite comprobar si todas las consultas cacheadas se han purgado.
ir a la publicación Jose Tomas Salvador · 30 sep, 2020 Hola Robert, comprueba si _SYSTEM es un usuario habilitado en tu instancia de IRIS. Según como instales, es posible que esté deshabilitado por defecto. Prueba también con el usuario superuser.
