Nouvelle publication

Encontrar

Question
· Avr 22

Linked Stored Procedure Call - Need Results to populate further logic

I was wondering if someone could help me. In the past I have been able to call external Stored Procedures through a SQL Outbound Connection and have them return me the EnsLib.SQL.Snapshot to use within a BPL to extract data.

But this time instead of using a SQL Outbound BO to make the Stored Procedure call, I decided to create a Linked Stored Procedure through the %JDBC_Server to point to the Stored Procedure out on MS SQL.

However, I am struggling to get the code just right to return the Column value from the Linked Stored Procedure.

 set result = ##class(EnsLib.SQL.Snapshot).%New()
 set result = $SYSTEM.SQL.Execute("CALL osuwmc_Utils_EnterpriseDirDb.InterfaceCheckConnectMedCtrID('$Get(MedCtrID)')")
 while result.%Next(){
  set Loc = result.Get("OSUguestRoleDTL")
 }

Does not return me the value I am looking for because the rest of my code fails.

However, if execute CALL osuwmc_Utils_EnterpriseDirDb.InterfaceCheckConnectMedCtrID('<value>') from the SQL Viewer it will return a Result. If I do a do result.%Display() it shows me the result, so what am I missing? This is the first time I have tried to call a Linked Stored Procedure from within Object Script.

I need to get the value that is being returned within "OSUguestRoleDTL" to help me determine how to route the message and populate addresses within the HL7 message.

2 Comments
Discussion (2)1
Connectez-vous ou inscrivez-vous pour continuer
Question
· Avr 22

DTL help - resolved, great help

New at DTL. I need some pointers on this DTL

For all Prosthetics orders:
when ORC-1(Order Control) is "NW" (New Order), need to update OBR-18(Placer Field 1) based on PV1-2 (Patient Class) value.
assumption is that the selection logic is that all prosthetics orders with OBR-18 field is always blank.
Description :
If PV1-2 is I, insert I in OBR-18
If PV1-2 is O, insert O in OBR-18
If PV1-2 is E, insert O in OBR-18
If PV1-2 is P, insert O in OBR-18
If PV1-2 is R, insert O in OBR-18
If PV1-2 is B, insert O in OBR-18

1 Comment
Discussion (1)1
Connectez-vous ou inscrivez-vous pour continuer
Question
· Avr 22

What the heck is a "Reentrant request"?

I'm playing with %Net.DB.Iris and stumbled over a mystery

set con=##class(%Net.DB.DataSource).CreateConnection(host,...)
set srv=con.CreateIris()
write srv.ClassMethodValue("%SYSTEM.Util","InstallDirectory")

Entering the above lines (in a terminal session) on my local instance yields the correct answer for:

host = "localhost"
host = the real IP of localhost (i.e. host="192.168...")
host = "10.x.y.dev" customers development system (over a VPN tunnel)

but for

host = "10.x.y.tst" (customers test system) I get an error:
 <THROW>zClassMethodValue+8^%Net.DB.Iris.1 *%Exception.StatusException ERROR #5001: Reentrant request

I don't see any reason for a "re-entry problem" in the three lines above, but maybe I'm blind...

If I execute the above three lines in a terminal session on customers dev-system (10.x.y.dev) and try to reach the testsystem (10.x.y.tst), I get the same error BUT if I do that on the test-system (10.x.y.tst) I can reach the dev-system (10.x.y.dev), i.e. no error.

Both customer instances are IRIS 2023.1.1/Win and my local instance is IRIS 2021.2/Linux

I can't figure out what's going on
- why do I get an error at all and
- what do that error means

Does anyone have any idea what's wrong and what this error message is trying to tell me or is it a case for WRC?

4 Comments
Discussion (4)1
Connectez-vous ou inscrivez-vous pour continuer
Article
· Avr 22 3m de lecture

Comment identifier les variables globales temporaires qui consomment de l'espace dans la base de données IRISTEMP

Rubrique FAQ InterSystems

Les variables globales temporaires stockées dans les bases de données IRISTEMP/CACHETEMP sont utilisées lorsqu'un processus n'a pas besoin de stocker des données indéfiniment, mais requiert les performances élevées des variables globales. Les bases de données IRISTEMP/CACHETEMP ne sont pas journalisées ; leur utilisation ne crée donc pas de fichiers journaux.

Le système utilise les bases de données IRISTEMP/CACHETEMP pour le stockage temporaire et les utilisateurs peuvent y accéder à cette fin.

Pour plus d'informations sur les variables globales temporaires et la base de données IRISTEMP, consultez le document suivant :

Globals temporaires et la base de données IRISTEMP

Les globales utilisées comme temporaires sont :

1. Variables globales temporaires du système (^IRIS.Temp*, ^%cspSession, ^CacheTemp*, ^mtemp*, etc.)
2. Variables globales temporaires mappées à IRISTEMP/CACHETEMP par l'utilisateur

3. Process private globals  (^||name, ^|"^"|name, ^["^"]name, ^["^",""]name, etc. )
4. Table de GLOBALE TEMPORAIRE

 -> La définition de la table est persistante (disponible pour tous les processus) et les données de la table sont stockées dans les données globales privées du processus (ne durent que pendant la durée du processus).

Les tailles 1 et 2 peuvent être vérifiées à l'aide de l'utilitaire ^%GSIZE:

USER>do ^%GSIZE

Directory name: c:\intersystems\iris\mgr\user\ => c:\intersystems\iris\mgr\iristemp\
                                               // Specify the iristemp database folder
All Globals? No => yes       // Yes to show all globals: 34 items selected
34 available globals
Show details?? No => No   //  No to not show detailed information 
Device:
Right margin: 80 =>

3,4 Les globales privées des processus peuvent être visualisées à l'aide de l'utilitaire ^GETPPGINFO

Pour plus d'informations sur l'utilitaire ^GETPPGINFO, consultez le document suivant :
About the ^GETPPGINFO utility [IRIS]
About the ^GETPPGINFO utility

L'exemple suivant répertorie les variables globales privées de tous les processus actuels 

 set ^||flintstones(1)="Fred"
 set ^||flintstones(2)="Wilma"
 znspace "%SYS"
 do ^GETPPGINFO("*")

Une autre méthode consiste à afficher le contenu de processus individuels utilisant des blocs globaux privés en grande quantité.

L'exemple suivant affiche le nombre de blocs globaux privés par processus supérieur ou égal à 20.

 set ns=$namespace
 znspace "%SYS"
 
 // Only processes with more PPG blocks than the total number of processes are included
 set st=##class(%SQL.Statement).%New()
 set status=st.%PrepareClassQuery("%SYS.ProcessQuery","AllFields")
 set rs=st.%Execute()
 while rs.%Next() {
    set pid=rs.%Get("Pid") // Process ID
    set cnt=rs.%Get("PrivateGlobalBlockCount") // Number of PPG blocks
    
    // When the number of PPG blocks per process is 0 or more, the contents are output (the following example shows 20 or more blocks).
    if cnt > 20 {
       set rs2=##class(%ResultSet).%New("%SYS.ProcessQuery:PPG")
       // "N" Do not return subscripts of a PPG, just return the root name
       // "B" Return the number of blocks used by the PPG (needs the "N" option)
       do rs2.Execute("*",pid,"NB")
       for {
          quit:'rs2.Next()
          write cnt_" PID:"_pid_", PPG name "_rs2.GetData(1)_" is using "_rs2.GetData(3)_" disc blocks",!
       }
    }
 }
 
 znspace ns
Discussion (0)1
Connectez-vous ou inscrivez-vous pour continuer
Article
· Avr 22 4m de lecture

Consideraciones al migrar de Oracle, MSSQL, etc. a IRIS

Migrar desde Oracle, MSSQL u otros sistemas de bases de datos puramente relacionales a un sistema multimodelo como InterSystems IRIS es una decisión estratégica que requiere una planificación y ejecución cuidadosas. Aunque esta transición ofrece beneficios significativos, como un mejor rendimiento, escalabilidad y soporte para arquitecturas modernas, también conlleva desafíos. En este artículo destacaré algunas de las consideraciones relacionadas con la codificación para asegurar una migración exitosa. Dejaré fuera del alcance de este artículo todo lo relacionado con la migración real de estructuras y datos.

Primero, cuando estáis considerando migrar a un sistema de base de datos diferente, necesitáis comprender vuestra lógica de negocio, ya sea del lado de la aplicación (servidor de aplicaciones) o del servidor de bases de datos. Básicamente, ¿dónde tenéis vuestras sentencias SQL que potencialmente tendréis que reescribir?

Cuando vuestra lógica de aplicación depende en gran medida de SQL ejecutado directamente dentro del código de la aplicación (en lugar de procedimientos almacenados o triggers en la base de datos), migrar desde una base de datos relacional a InterSystems IRIS requiere un examen cuidadoso de vuestras sentencias SQL. Veamos algunos de los factores más importantes que debéis tener en cuenta.

  1. Diferencias en el dialecto SQL. SQL de IRIS admite el estándar SQL-92. Esto no significa que no estén implementadas algunas funcionalidades más modernas. Simplemente significa que necesitáis comprobarlo de antemano. Por ejemplo, las funciones de ventana aparecieron en SQL:2003, pero aún así podéis escribirlas en IRIS.
--window function
select id, rating
  from (select a.id, 
               r.rating, 
               avg(r.rating) over () as avg_rating 
          from SQLUSER.Actor a join SQLUser.Review r on a.id = r.Reviews) as sub 
 where rating > avg_rating

Al mismo tiempo, los nuevos tipos de datos complejos, como XML, JSON, Arrays y tipos de datos geográficos, no están soportados. Así que la siguiente consulta:

SELECT a.id, 
       a.firstname, 
       ARRAY_AGG(r.rating) AS ratings 
  FROM SQLUSER.Actor a LEFT JOIN SQLUser.Review r ON a.id = r.Reviews 
GROUP BY  a.firstname

devolverá un error: ERROR #5540: SQLCODE: -359 Message: User defined SQL function 'SQLUSER.ARRAY_AGG' does not exist

Pero no es el fin del mundo. Hay muchas funciones integradas que os permitirán reescribir las consultas para obtener el resultado esperado.

2. Funciones integradas. Los distintos sistemas de gestión de bases de datos tienen diferentes funciones integradas. Por lo tanto, necesitáis comprender cómo se corresponden con las disponibles en IRIS. Aquí tenéis varios ejemplos de lo que os estoy comentando: funciones usadas en Oracle y sus equivalentes en IRIS.

Oracle IRIS
NVL ISNULL(field, default_value)
substr $extract(field, start_pos, end_pos)
instr $find(field, text_to_find)
concat {fn CONCAT(string1,string2)}

Cuando vuestra lógica SQL principal reside dentro de la base de datos (por ejemplo, procedimientos almacenados, triggers, vistas), migrar a InterSystems IRIS requiere un enfoque diferente. Aquí tenéis algunas consideraciones:

  1. Migración de objetos de base de datos
    1. Todos los procedimientos almacenados deben reescribirse usando ObjectScript. Esta también puede ser una buena oportunidad para cambiar al modelo orientado a objetos, ya que obtendréis una tabla igualmente al crear una clase. Sin embargo, trabajar con clases os permitirá escribir métodos (que pueden llamarse como procedimientos almacenados) y usar todo el potencial del paradigma orientado a objetos.
    2. Los triggers, índices y vistas están todos soportados por IRIS. Incluso podéis dejar las vistas tal como están si las columnas de las tablas se mantienen iguales y no utilizan funciones o sintaxis no soportadas (ved el punto anterior).
  2. La migración de definiciones también es importante y puede presentar algunos desafíos. Primero, debéis hacer una correspondencia cuidadosa de los tipos de datos de vuestra base de datos anterior con los de IRIS, especialmente si estáis usando tipos de datos complejos. Además, al tener más flexibilidad con los índices, quizás queráis redefinirlos de forma distinta.

Aquí tenéis algunas cosas que debéis considerar al decidir migrar a InterSystems IRIS desde otra base de datos relacional. Es una decisión estratégica que puede desbloquear beneficios significativos, incluyendo una mayor escalabilidad, rendimiento y eficiencia. Sin embargo, una planificación cuidadosa es crucial para asegurar una transición fluida y abordar necesidades de compatibilidad, transformación de datos y refactorización de la aplicación.

Discussion (0)1
Connectez-vous ou inscrivez-vous pour continuer