Hola Miguel Angel, 

Lo que buscas se hace muy facil con lo que llamamos "deployed classes" o "deployed mode". Este es el método que usan la mayoría de clientes que quieren evitar tener el código visible y que se puedan modificar. 


En modo desplegado o deployed mode, el código de los métodos se eliminan y quedan en su forma compilada. Las clases en este modo no se pueden exportar ni compilar, pero sus subclases sí, siempre que no estén desplegadas.

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

Écha un vistazo a la documentación y comprueba si os sirve. El método que comentas de las bases de datos encriptadas sería también posible, pero lo veo más enrevesado. 

Añadir que en la mayoría de las veces que vamos a utilizar este tipo de queries, vamos a querer obtener varios resultados dentro de un array Json, y por tanto podemos usar JSON_ARRAYAGG de una forma muy sencilla: 

SELECT TOP 3 JSON_ARRAYAGG(JSON_OBJECT('title':'Person from','country':UCASE(Home_State),'table':%TABLENAME,'name':Name,'id':%ID,'age':Age ABSENT ON NULL)) "JSON data" 
FROM Sample.Person

Obteniendo el array JSON en una variable (pues solo devolverá una fila) listo para usar: 

Es difícil saber qué está pasando sin ver el código y probarlo. Antes de verlo, diría que el tableare no tiene definido parámetros en la descripción de la tabla. Ejemplo:

<tablePane id="table"
           sql="SELECT ID,Name FROM MyApp.Employees
                WHERE Name %STARTSWITH ? ORDER BY Name"
           >
     <parameter value="Z"/>
</tablePane>

Podrías intentar simplificar el código al máximo en una clase copiada de la original, y, cuando no puedas reducir más el código, nos lo mandes y podamos echarle un vistazo. 

Hola Iyer,

Sí, es posible en Iris. Mirando en la documentación de SQL podemos ver un ejemplo sencillo de crear un indice en la propiedad State de la clase serial Sample.Address, dentro siempre de la clase persistente (Sample.Person)

https://docs.intersystems.com/iris20221/csp/docbook/Doc.View.cls?KEY=RSQ...

Pego la parte de la documentación donde se indica:

--

Field in an Embedded Object (%SerialObject)

To index a field in an embedded object, you create an index in the table (%Persistent class) referencing that embedded object. In CREATE INDEX the field-name specifies the name of the referencing field in the table (%Persistent object) joined by an underbar to the field name in the embedded object (%SerialObject), as shown in the following example:

CREATE INDEX StateIdx ON TABLE Sample.Person (Home_State)

Here Home is a field in Sample.Person that references the embedded object Sample.Address, which contains the State field.

Only those embedded object records associated with the persistent class referencing property are indexed. You cannot index a %SerialObject property directly.

For further details on defining embedded objects (also known as serial objects) refer to Embedded Object (%SerialObject); for further details on indexing a property (field) defined in an embedded object, refer to Indexing an Embedded Object (%SerialObject) Property.

Hola Yone, 

Comentarte que las preguntas enviadas a la comunidad no tienen porqué ser respondidas por personal de InterSystems. La comunidad está abierta a que todos compartamos nuestra dudas y soluciones (incluidos los empleados de InterSystems, que, de vez en cuando también preguntamos). Si necesitas algo urgente y quieres estar segura de obtener respuesta por nuestra parte, lo mejor es que nos abras un caso en soporte desde el WRC.

Respecto a tu pregunta, todo lo que se guarda el un global de una base de datos distinta a la temporal, va a ser persistente. En el caso de los GlobalCharacter, se van a guardar en un global y por tanto va a ser persistente (es decir, que una vez guardado, si reinicias el servidor, el dato va a estar ahí). 

Al ser persistente, si los mensajes no se purgan correctamente, podría dejar nodos huérfanos. Todo dependerá de como hayas implementado la clase y las purgas. Si tienes dudas al respecto, te animo a que abras otro nuevo hilo. 

Finalmente, tal y como indica la documentación, lo suyo es que uses el tipo %Stream.GlobalCharacter, que tiene la misma función y es el que se va a mantener en futuras versiones. El tipo anterior, por estar "deprecated" dejará de funcionar en alguna versión futura.

Manel, 

Muy bien y cortito….. pero se ve un poco viejuno y críptico. Me recuerda a unos concursos muy antiguos llamados código C ofuscadowink

Aquí te dejo uno más "modernito", con uso de (JSON-dynamic Objects)  mucho más sencillo de entender.

Supéralo! cheeky

set texto="If, you can read"


set nato={"A":"Alfa","N":"November","B":"Bravo","O":"Oscar","C":"Charlie","P":"Papa","D":"Delta","Q":"Quebec","E":"Echo","R":"Romeo","F":"Foxtrot","S":"Sierra","G":"Golf","T":"Tango","H":"Hotel","U":"Uniform","I":"India","V":"Victor", "J":"Juliett","W":"Whiskey","X":"Xray","K":"Kilo","L":"Lima","Y":"Yankee","M":"Mike","Z":"Zulu","?":"?",".":".","!":"!"," ":" ",",":","}

set texto=$ZCONVERT(texto,"U")
for i=1:1:$LENGTH(texto) { write nato.%Get($EXTRACT(texto,i)) }
----
IndiaFoxtrot, YankeeOscarUniform CharlieAlfaNovember RomeoEchoAlfaDelta

Y para probarlo, basta con copiar-pegar en el terminal, que importar y compilar suele dar mucha pereza.

Cierto!

Sólo nos acordamos cuando nos hacen falta, y, os puedo garantizar que muchísimas veces las copias que pensábamos que están bien, no lo están, con la consiguiente pérdida de tiempo/datos y el estrés que genera. Si te digo la verdad, hice esta aplicación para demostrar lo sencillo que es validar copias y que no haya excusas wink

Hola, 

En mac hay terminales potentes como Iterm, pero no siguen la filosofía del Reflection. No tengo claro si quieres seguir usando Mac o Windows. Si es Mac, tendrás que buscar un terminal tipo VT o similar que salga como necesitas. Creo haber usado un terminal de AS400 en mac y funcionaba bien o parecido a los que comentas. (Prueba a buscar as400 terminal mac en google, sale uno llamado MochaSoft que creo que te pueda servir).

Una vez tengas el terminal que quieras puedes conectarte haciendo un ssh al mac y usarlo como cliente remoto sobre tu mac y de ahí hacer la conexión al terminal docker. Puede ser un poco lioso, pero si te pones a probarlo y no lo consigues dime el terminal que has elegido y le echo un ojo, pues seguro que hay una forma. 

Respecto a migrar, creo que puedes intentar cambiar la base de datos CACHE.DAT y renombrarla a IRIS.DAT. Esto te debería permitir acceder desde IRIS.  Como la 5.2 es un poco antigua, sería ideal que pasases la base de datos a una versión Caché más reciente y luego hacer el cambio de nombre que te comentaba. Prueba a ver que tal!

Hola, 

Te respondo por aquí también por si a alguien más le puede servir. 

Si tenemos en cuenta que las consultas congeladas se basan en las consultas cacheadas, podemos entender que si no hay consultas cacheadas no vamos a tener consultas congeladas. 

Dicho esto, la mejor manera de estar seguro de no tener consultas congeladas es 

  1. Descongelar
  2. Purgar consultas

Es posible que al sobreescribir la lógica algunas consultas se purguen automáticamente y no haría falta hacer lo anterior, sería algo a probar, pero no merece el esfuerzo y el análisis cuando los pasos anteriores son tan rápidos y claros, además de confirmarte que es lo que necesitas. 

Respecto a la segunda pregunta, las consultas no se congelan automáticamente salvo en upgrades de versiones mayores. 

Hola Kurro, 

Si has conseguido que funcione liberando otros registros de la tabla de Lock, entonces tiene toda la pinta que la tabla de locks se ha llenado y por eso no puede darte más bloqueos. 

Si se ha llenado, seguramente tengas entradas en el cconsole.log al estilo 

"LOCK TABLE FULL"

Este error puede llegar a ser grave, pues afecta a todos los locks y es posible que la aplicación y los usuarios se paralicen a la espera de que se vaya liberando dicha tabla, haciendo por tanto un cuello de botella. 

Las buenas noticias, es que probablemente se deba a que no esté bien dimensionada, y la manera de arreglarlo sea simplemente aumentando el tamaño de la tabla de Locks y el GMHeap. Por defecto están muy bajos (1MB) y el consejo cuando se empieza a ver este tipo de mensajes es aumentar y continuar monitorizando. 

Si compruebas que tienes los valores por defecto (de 1MB), mi consejo es aumentarlo al menos a 10MB (que no es prácticamente nada hoy en día) y continuar monitorizando (mirando el cconsole.log e incluso la rutina ^LOCKTAB:

%SYS>do ^LOCKTAB
                            Node Name: IRISTEST
                   LOCK table entries at 09:52AM  04/20/2020
                16746736 bytes usable, 16774512 bytes available.

Si vieses que se vuelve a llenar frecuentemente, es probable que debas aumentarla más, pues tu aplicación, tal y como está diseñada, consume más locks (no es malo ni bueno). 

Ojo, es importante que si aumentas el tamaño de la tabla de locks, has de aumentar el GMHeap en la misma proporción, pues el GMHeap contiene la tabla de locks. 

Te dejo un link a la documentación: 

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Finalmente, entiendo que este problema te está dando en un servidor de pruebas o desarrollo, si fuese en producción, te recomendaría abrir un caso con soporte (WRC) pues es la manera más segura y rápida de asegurarte una respuesta y que te podamos ayudar.  El community está genial pero si te corre prisa, mejor el WRC ;-)