accéder à la publication Sylvain Guilbaud · Juil 17 Merci @Irène Mykhailova pour ces consignes, toujours utiles. Je ne sais pas si c'est intentionnel de ta part pour garantir que ton article soit lu correctement par la communauté, mais une faute de frappe s'est glissée : %SYSTEM.JSON n'est pas une classe existante dans IRIS. Ou s'agit-il simplement d'une hallucination non vérifiée, qui prouverait que tu dois appliquer toi-même tes recommandations pour une utilisation optimale de l'IA générative ? J'opte pour la première option 😊
accéder à la publication Sylvain Guilbaud · Juin 5 L'utilisation de multiples namespaces n'induit pas de surconsommation mémoire directe, mais une mauvaise gestion des mappings ou une configuration sous-optimale des caches peut dégrader les performances. Une planification attentive des accès aux données et des paramètres système adaptés (cache global, $ZSTORAGE, huge pages) permet de maintenir une empreinte mémoire efficace. 1. Mécanisme des namespaces et bases de données Un namespace est une entité logique sans surcoût mémoire intrinsèque. Chaque namespace accède à des bases de données (fichiers IRIS.DAT) via des mappings prédéfinis ou personnalisés. La consommation mémoire dépend principalement : Du cache des globals (mémoire partagée pour les données) Du cache des routines (mémoire partagée pour le code) De la configuration des processus individuels ($ZSTORAGE). 2. Impact des accès multi-bases Accès concurrents à plusieurs bases : Augmente l'utilisation du cache global si les données sont dispersées. Peut entraîner une fragmentation mémoire si les allocations/désallocations sont fréquentes. Mapping intelligent : Des mappings permettent d'optimiser l'accès aux données sans dupliquer les buffers, en partageant des données de référence ou du code entre plusieurs namespaces. 3. Optimisations recommandées Configuration du cache global : Allouer 25-30% de la RAM disponible pour les buffers 8KB (valeur par défaut). Utiliser des huge pages Linux pour réduire la surcharge mémoire. Limite par processus : Ajuster Maximum Per-Process Memory (KB) via le portal (256KB à 2TB). Surveiller les erreurs <STORE> pour détecter les besoins d'ajustement. Stratégie de déploiement : Regrouper les données fréquemment accédées dans une même base ou définir un mapping dans %ALL pour donner un accès à tous les namespaces aux données fréquentes. Utiliser des bases temporaires distinctes pour les opérations transactionnelles lourdes. 4. Comparaison avec les bases en mémoire InterSystems IRIS évite les écueils des bases purement en mémoire : Gestion dynamique : Seules les données actives sont conservées en mémoire via un mécanisme de buffer pool. Persistance native : Élimine le besoin de recharger les données après un redémarrage. Benchmarks : IRIS est très souvent plus rapide en requêtes SQL que des solutions in-memory pures.
accéder à la publication Sylvain Guilbaud · Juin 4 @Corentin Blondeau, c'est la nature des 20 flux qui doit être considérée pour décider du nombre de namespaces. Si les 20 flux sont tous liés entre eux d'un point de vue métier, un seul namespace est recommandé. Si parmi ces 20 flux, une vraie séparation métier existe, il est recommandé de les séparer dans plusieurs namespaces, même si certains d'entre eux ne reçoivent qu'un flux, la séparation offrira plus de souplesse dans l'administration et la gestion opérationnelle. L'impact sur la consommation mémoire est marginal ; seuls les processus Ens.Actor, Ens.Alarm, Ens.Alert, Ens.MonitorService, Ens.ProductionMonitorService, Ens.ScheduleHandler seront dupliqués pour chaque nouveau namespace. Chaque instance IRIS pouvant supporter jusqu'à 2048 namespaces, il ne faut pas s'en priver dès l'instant où le bénéfice de l'isolation est au rendez-vous 😉
accéder à la publication Sylvain Guilbaud · Juin 4 Dans InterSystems IRIS, le choix entre un seul namespace ou plusieurs dépend des besoins en isolation, sécurité, gestion du code et performances. Si tous les flux sont homogènes d'un point de vue métier, il n'est pas nécessaire de recourir à plusieurs namespaces (plusieurs client utilisent en production des centaines ou des milliers de flux dans un seul namespace). L'utilisation de plusieurs namespaces offre cependant plusieurs avantages, notamment liés à la sécurité et à l'isolation des processus et données, dès l'instant où vous avez des flux répondant à des besoins métiers hétérogènes ou à des utilisations spécifiques. Avantages d'utiliser plusieurs namespaces Isolation des environnements Chaque namespace peut être dédié à un usage spécifique (développement, test, production). Cela réduit les risques de conflits entre configurations. Sécurité renforcée Les mappings contrôlent précisément l'accès aux données et au code. Un namespace peut restreindre l'accès à certaines bases de données via des règles de mapping global/routine. Gestion modulaire Configuration indépendante pour chaque flux d'intégration (interopérabilité) Mise à jour/redéploiement partiel sans impacter l'ensemble du système Inconvénients de multiples namespaces Complexité accrue de l’administration Plus il y a de namespaces, plus la gestion des mappings, des bases de données associées, des configurations de sécurité, des accès utilisateurs et des stratégies de sauvegarde devient complexe. Chaque namespace nécessite une configuration propre (databases, mappings, sécurité), ce qui multiplie les tâches d’administration et augmente le risque d’erreurs humaines lors des modifications ou migrations. Gestion des sauvegardes et restaurations La multiplication des namespaces entraîne une augmentation du nombre de fichiers IRIS.DAT à sauvegarder et restaurer. Cela peut rallonger les temps de sauvegarde/restauration et compliquer la gestion des versions et des points de reprise, car il faut garantir la cohérence entre plusieurs bases de données et namespaces. Verrouillage et contention Les locks sur les globals sont globaux à la base de données : si plusieurs namespaces accèdent à la même base de données via des mappings, ils peuvent se retrouver en concurrence sur les mêmes verrous, ce qui peut générer des contentions inattendues et compliquer le diagnostic des problèmes. Mise à jour et déploiement Mettre à jour du code ou des configurations dans plusieurs namespaces nécessite de répéter les opérations, ce qui augmente le risque d’incohérences entre environnements et la charge de travail pour les équipes DevOps. Surcoût de maintenance Chaque namespace ajoute des tâches de maintenance (monitoring, logs, gestion des utilisateurs, etc.). À grande échelle, cela peut devenir difficile à suivre et à automatiser sans outils adaptés Difficulté de suivre une trace complète dans Visual Trace : un inconvénient majeur de l’utilisation de plusieurs namespaces, lorsque les flux métier sont liés. Visual Trace ne permet de visualiser que les messages et les transactions d’un seul namespace à la fois. Si un flux métier traverse plusieurs productions réparties sur différents namespaces, il n’est pas possible de visualiser le parcours global du message ou de la transaction dans une seule vue Visual Trace. L’opérateur ou le développeur doit ouvrir séparément chaque namespace dans le Management Portal, puis rechercher manuellement les messages correspondants (souvent avec des identifiants différents ou des métadonnées partielles), ce qui rend le diagnostic et l’analyse chronologique beaucoup plus complexes. Il n’existe pas de corrélation automatique des traces entre namespaces : chaque Visual Trace est limité à l’espace de noms courant, sans suivi transversal natif. Dès lors que des flux d’intégration sont distribués sur plusieurs namespaces, la traçabilité globale via Visual Trace devient morcelée, ce qui complique considérablement le support, la maintenance et l’investigation des incidents métier. Isolation des processus L’isolation des processus dans chaque espace de noms (namespace) InterSystems IRIS est un sujet important pour la sécurité, la stabilité et la gestion de vos applications. Voici une explication détaillée : 1. Qu’est-ce qu’un namespace dans IRIS ? Un namespace est un environnement logique qui regroupe : Une ou plusieurs bases de données (globals, routines) Des mappings de code et de données Des configurations spécifiques (services, productions, etc.) 2. Isolation des processus : ce qui est isolé a. Espace d’adressage des données Chaque namespace a ses propres mappings de bases de données. Les globals et routines sont isolés par défaut : un processus dans le namespace A n’accède pas aux données du namespace B (sauf si mapping explicite). b. Contexte d’exécution Les processus lancés dans un namespace (par exemple, un job d’intégration, une session terminal, un service REST) s’exécutent dans le contexte de ce namespace. Les variables système, le $namespace courant, et les paramètres de session sont propres à chaque processus et à chaque namespace. c. Productions d’interopérabilité Les productions (Ensemble/IRIS Interoperability) sont isolées par namespace : chaque namespace a sa propre production, ses propres Business Services, Processes et Operations. Les queues, logs, et messages sont séparés. d. Sécurité Les droits d’accès (Rôle, Ressource) peuvent être définis par namespace. Les utilisateurs peuvent être limités à certains namespaces via la configuration des applications web/services. 3. Ce qui n’est PAS isolé Processus système : Les processus système (ex : le démon d’écriture, le garbage collector) sont globaux à l’instance IRIS. Caches partagés : Le cache de routines et de données est partagé entre tous les namespaces. Mémoire partagée (gmheap) : Les structures internes sont communes. Journalisation (Write Image Journal, Journaux d’audit) : Certains fichiers de journalisation sont globaux. 4. Exemple pratique Si vous lancez un job dans le namespace A, il ne voit que les données et le code de A (sauf mapping). Si un processus dans le namespace B plante, il n’impacte pas directement les jobs du namespace A. Les productions d’interopérabilité ne partagent pas leurs queues ou messages. 5. Limites de l’isolation Processus : Tous les processus sont visibles dans la vue système (^%SS, Management Portal), quel que soit leur namespace d’origine. Ressources système : Les processus de tous les namespaces consomment la même mémoire, CPU et I/O disque. 6. Résumé Élément Isolé par namespace Global à l’instance Données (globals) ✔️ Code (routines/classes) ✔️ Productions interop ✔️ Processus système ✔️ Caches (données/routines) ✔️ Mémoire partagée ✔️ Journalisation ✔️ L’isolation des processus dans chaque namespace est forte sur le plan applicatif (données, code, productions), mais partielle sur le plan système (ressources partagées). Pour une isolation maximale, il faut combiner la séparation par namespace avec des politiques de sécurité et, si nécessaire, des instances IRIS séparées. En conclusion, une architecture multi-namespaces est préférable pour des flux hétérogènes nécessitant une isolation forte, malgré une complexité opérationnelle accrue. Pour des flux homogènes, un namespace unique avec scaling vertical (CPU/mémoire) peut suffire.
accéder à la publication Sylvain Guilbaud · Mai 30 Bonjour Cécile, L'erreur "BP completion cleanup error deleting BP instance" dans InterSystems IRIS survient généralement lors de la suppression d'une instance de Business Process (BP) après son exécution.Si le BP est configuré avec PoolSize=0, l'action de suppression des instances peut échouer car le système ne peut pas contrôler tous les threads simultanés. As-tu plus d'informations dans l'Event Log : Interoperability > Event Log ?
accéder à la publication Sylvain Guilbaud · Jan 31 Dans un environnement conteneurisé, vous pouvez gérer l'heure de votre conteneur via la variable TZ ou via les répertoires /etc/timezone et /etc/localtime : environment: - TZ=Europe/Paris volumes: - "/etc/timezone:/etc/timezone:ro" - "/etc/localtime:/etc/localtime:ro" Vous pouvez retrouver des exemples complets ici : IRIS Community IRISHealth_Community IRIS production IRISHealth production
accéder à la publication Sylvain Guilbaud · Oct 14, 2024 Un grand bravo à tous les participants et un grand merci pour vos articles fort utiles 😃
accéder à la publication Sylvain Guilbaud · Juil 19, 2024 MayVilleHop est une plateforme innovante de coordination ville-hôpital développée pour le territoire de la Mayenne, basée sur la solution HealthShare d'InterSystems. Voici une description fonctionnelle et technique de cette plateforme : Fonctionnalités principales 1. Gestion des demandes semi-urgentes : La plateforme permet aux médecins de ville de soumettre des demandes d'hospitalisation semi-urgentes, avec une réponse garantie sous 48 heures[1][3]. 2. Téléexpertise : Un service de téléexpertise est intégré, permettant aux médecins de ville de consulter des spécialistes hospitaliers à distance[1]. 3. Espace de discussion : Les professionnels de santé disposent d'un espace dédié pour échanger directement sur la plateforme[1]. 4. Accès aux dossiers médicaux : Les utilisateurs peuvent accéder à la synthèse du dossier médical hospitalier du patient ainsi qu'au Dossier Médical Partagé (DMP)[1]. 5. Système de notifications : La plateforme envoie des notifications pour chaque événement important du parcours de soins du patient, comme l'admission, l'hospitalisation et la sortie[1]. 6. Annuaire des professionnels : Un annuaire des professionnels de santé hospitaliers est intégré à la plateforme[1]. Aspects techniques 1. Authentification sécurisée : Les professionnels de santé se connectent à la plateforme via leur carte CPS, garantissant un accès sécurisé[1]. 2. Interopérabilité : HealthShare permet l'interopérabilité entre les différents systèmes d'information de santé, facilitant le partage de données entre la ville et l'hôpital[3]. 3. Identification transversale : La plateforme assure une identification sécurisée et transversale des patients dans l'ensemble des systèmes[4]. 4. Analyse populationnelle : HealthShare offre des capacités d'analyse des données de santé de la population, permettant d'identifier les besoins en prévention et de notifier les équipes de prise en charge[3]. 5. Personnalisation : La plateforme permet une personnalisation de l'utilisation pour les médecins, s'adaptant à leurs besoins spécifiques[2]. 6. Sécurité des données : En tant que solution d'InterSystems, HealthShare intègre des fonctionnalités avancées de sécurité pour protéger les données de santé sensibles. MayVilleHop vise à fluidifier la communication entre l'hôpital et la ville, optimiser le temps médical, et simplifier les parcours de soins complexes. Cette plateforme s'inscrit dans une démarche plus large de transformation numérique du système de santé, contribuant à renforcer le maillage territorial et la collaboration entre les différents acteurs de santé[4]. Citations:[1] https://www.youtube.com/watch?v=MjlaarmRx98[2] https://www.esante-paysdelaloire.fr/media-files/4630/le-numerique-en-san...[3] https://www.youtube.com/watch?v=cmn1_s7c244[4] https://emfps.fr/outils-de-coordination-ville-hopital/[5] https://www.youtube.com/watch?v=wovGmt4ig5Y
accéder à la publication Sylvain Guilbaud · Juil 9, 2024 Bonjour Moussa, le messages.log indique une version IRIS 2023.1 : Si tu utilises ARG IMAGE=intersystemsdc/irishealth-community tu obtiendras une version 2024.1 NB : pour récupérer régulièrement les images plus récentes, le repository officiel InterSystems est https://containers.intersystems.com/contents Les noms des différentes images régulièrement mises-à-jour sont : EXTENDED_MAINTENANCE=latest-em CONTINUOUS_DELIVERY=latest-cd DEVELOPER_PREVIEW=latest-preview IMAGE_IRIS_EM=containers.intersystems.com/intersystems/irishealth-community:$EXTENDED_MAINTENANCE IMAGE_IRIS_CD=containers.intersystems.com/intersystems/irishealth-community:$CONTINUOUS_DELIVERY IMAGE_IRIS_PREVIEW=containers.intersystems.com/intersystems/irishealth-community:$DEVELOPER_PREVIEW Tu peux utiliser ce repo pour tester les différentes versions d'IRIS for Health : https://github.com/SylvainGuilbaud/IRISHealth_community
accéder à la publication Sylvain Guilbaud · Juil 8, 2024 Bonjour @Moussa SAMB le pb vient de la licence expirée de la version IRIS 2023.1.1 éditée en juillet 2023. Je t'invite à utiliser une version plus récente pour pallier le pb.
accéder à la publication Sylvain Guilbaud · Juin 6, 2024 Bonjour @Julia Pertin pour tester un objet dynamique vide tu peux utiliser la méthode d'instance %Size() qui renverra 0 IRISAPP>set monobjet={} IRISAPP>write monobjet.%Size() 0 IRISAPP>zw monobjet monobjet={} ; <DYNAMIC OBJECT> IRISAPP>set monobjet.data="une valeur" IRISAPP>write monobjet.%Size() 1 IRISAPP>zw monobjet monobjet={"data":"une valeur"} ; <DYNAMIC OBJECT>
accéder à la publication Sylvain Guilbaud · Avr 25, 2024 Simplement en utilisant l'option Resource dans une instruction CreateDatabase de la section [Actions] du fichier merge.cpf : [Actions] CreateResource:Name=%DB_IRISAPP_DATA,Description="IRISAPP_DATA database" CreateDatabase:Name=IRISAPP_DATA,Directory=/usr/irissys/mgr/IRISAPP_DATA,Resource=%DB_IRISAPP_DATA CreateResource:Name=%DB_IRISAPP_CODE,Description="IRISAPP_CODE database" CreateDatabase:Name=IRISAPP_CODE,Directory=/usr/irissys/mgr/IRISAPP_CODE,Resource=%DB_IRISAPP_CODE CreateNamespace:Name=IRISAPP,Globals=IRISAPP_DATA,Routines=IRISAPP_CODE,Interop=1
accéder à la publication Sylvain Guilbaud · Avr 23, 2024 Bonjour @Alin Soare, pouvez-vous nous donner plus de détails sur votre besoin et sur ce que vous ne parvenez pas à faire ? La commande WRITE fait partie des instructions de base d'IRIS (et même depuis l'origine du langage MUMPS, pré-existant à Caché, Ensemble, IRIS).
accéder à la publication Sylvain Guilbaud · Avr 19, 2024 Avec le résultat suivant : python account.py Deposit succeeded: Balance after deposit: 100 Deposit of negative amount failed as expected: Deposit amount must be non-negative Withdrawal succeeded: Balance after withdrawal: 50 Withdrawal of more than available balance failed as expected: Insufficient funds Balance invariant holds true Balance invariant violated as expected: Balance invariant violated: Balance is negative Account operations completed successfully
accéder à la publication Sylvain Guilbaud · Avr 19, 2024 Exemple en Python : class Account: def __init__(self): self.balance = 0 def deposit(self, amount): if amount < 0: raise ValueError("Deposit amount must be non-negative") old_balance = self.balance self.balance += amount # Postconditions if self.balance != old_balance + amount: raise ValueError("Postcondition failed: Balance calculation error") def withdraw(self, amount): if amount < 0: raise ValueError("Withdrawal amount must be non-negative") if self.balance < amount: raise ValueError("Insufficient funds") old_balance = self.balance self.balance -= amount # Postconditions if self.balance != old_balance - amount: raise ValueError("Postcondition failed: Balance calculation error") def check_balance_invariant(self): if self.balance < 0: raise ValueError("Balance invariant violated: Balance is negative") @classmethod def test_account(cls): account = cls() try: # Test depositing a positive amount account.deposit(100) print("Deposit succeeded: Balance after deposit:", account.balance) # Test depositing a negative amount (should fail) account.deposit(-50) except ValueError as e: print("Deposit of negative amount failed as expected:", e) else: raise ValueError("Deposit of negative amount unexpectedly succeeded") try: # Test withdrawing a valid amount account.withdraw(50) print("Withdrawal succeeded: Balance after withdrawal:", account.balance) # Test withdrawing more than the available balance (should fail) account.withdraw(200) except ValueError as e: print("Withdrawal of more than available balance failed as expected:", e) else: raise ValueError("Withdrawal of more than available balance unexpectedly succeeded") try: # Check balance invariant (should succeed) account.check_balance_invariant() print("Balance invariant holds true") except ValueError as e: print("Balance invariant violated:", e) # Intentionally set balance to negative value to trigger balance invariant failure account.balance = -10 try: # Check balance invariant (should fail) account.check_balance_invariant() except ValueError as e: print("Balance invariant violated as expected:", e) else: raise ValueError("Balance invariant unexpectedly held true") print("Account operations completed successfully") # Run the test Account.test_account()
accéder à la publication Sylvain Guilbaud · Avr 19, 2024 Avec le résultat suivant : write ##class(MyApp.Account).TestAccount() Deposit succeeded: Balance after deposit: 100 Deposit of negative amount failed as expected: ERROR #5001: Deposit amount must be non-negative Withdrawal succeeded: Balance after withdrawal: 50 Withdrawal of more than available balance failed as expected: ERROR #5001: Insufficient funds Balance invariant holds true Balance invariant violated as expected: ERROR #5001: Balance invariant violated: Balance is negative Account operations completed successfully 1
accéder à la publication Sylvain Guilbaud · Avr 19, 2024 Exemple en ObjectScript Include %occErrors Class MyApp.Account Extends %Persistent { Property Balance As %Numeric; /// Deposit money into the account Method Deposit(amount As %Numeric) As %Status { // Preconditions If amount < 0 { Return $$$ERROR($$$GeneralError, "Deposit amount must be non-negative") } // Store the old balance Set oldBalance = ..Balance // Update balance Set ..Balance = oldBalance + amount // Postconditions If (..Balance '= $$$NULLOREF) && (..Balance '= (oldBalance + amount)) { Return $$$ERROR($$$GeneralError, "Postcondition failed: Balance calculation error") } Quit $$$OK } /// Withdraw money from the account Method Withdraw(amount As %Numeric) As %Status { // Preconditions If amount < 0 { Return $$$ERROR($$$GeneralError, "Withdrawal amount must be non-negative") } If (..Balance = $$$NULLOREF) || (..Balance < amount) { Return $$$ERROR($$$GeneralError, "Insufficient funds") } // Store the old balance Set oldBalance = ..Balance // Update balance Set ..Balance = oldBalance - amount // Postconditions If (..Balance '= $$$NULLOREF) && (..Balance '= (oldBalance - amount)) { Return $$$ERROR($$$GeneralError, "Postcondition failed: Balance calculation error") } Quit $$$OK } /// Invariant: Balance should always be non-negative Method CheckBalanceInvariant() As %Status { Set tSC = $$$OK If ..Balance < 0 { Set tSC = $$$ERROR($$$GeneralError, "Balance invariant violated: Balance is negative") } Quit tSC } /// Class method to test the Account class ClassMethod TestAccount() As %Status { // Create a new instance of Account Set account = ##class(MyApp.Account).%New() // Initialize the balance Set account.Balance = 0 // Test depositing a positive amount Set tSC = account.Deposit(100) If $$$ISERR(tSC) { Write "Deposit failed: ", $system.Status.GetErrorText(tSC), ! Quit tSC } Write "Deposit succeeded: Balance after deposit: ", account.Balance, ! // Test depositing a negative amount (should fail) Set tSC = account.Deposit(-50) If $$$ISERR(tSC) { Write "Deposit of negative amount failed as expected: ", $system.Status.GetErrorText(tSC), ! } Else { Write "Deposit of negative amount unexpectedly succeeded", ! Quit $$$ERROR($$$GeneralError, "Deposit of negative amount unexpectedly succeeded") } // Test withdrawing a valid amount Set tSC = account.Withdraw(50) If $$$ISERR(tSC) { Write "Withdrawal failed: ", $system.Status.GetErrorText(tSC), ! Quit tSC } Write "Withdrawal succeeded: Balance after withdrawal: ", account.Balance, ! // Test withdrawing more than the available balance (should fail) Set tSC = account.Withdraw(200) If $$$ISERR(tSC) { Write "Withdrawal of more than available balance failed as expected: ", $system.Status.GetErrorText(tSC), ! } Else { Write "Withdrawal of more than available balance unexpectedly succeeded", ! Quit $$$ERROR($$$GeneralError, "Withdrawal of more than available balance unexpectedly succeeded") } // Check balance invariant (should succeed) Set tSC = account.CheckBalanceInvariant() If $$$ISERR(tSC) { Write "Balance invariant violated: ", $system.Status.GetErrorText(tSC), ! Quit tSC } Write "Balance invariant holds true", ! // Intentionally set balance to negative value to trigger balance invariant failure Set account.Balance = -10 // Check balance invariant (should fail) Set tSC = account.CheckBalanceInvariant() If $$$ISERR(tSC) { Write "Balance invariant violated as expected: ", $system.Status.GetErrorText(tSC), ! } Else { Write "Balance invariant unexpectedly held true", ! Quit $$$ERROR($$$GeneralError, "Balance invariant unexpectedly held true") } Write "Account operations completed successfully", ! Quit $$$OK } Storage Default { <Data name="AccountDefaultData"> <Value name="1"> <Value>%%CLASSNAME</Value> </Value> <Value name="2"> <Value>Balance</Value> </Value> </Data> <DataLocation>^MyApp.AccountD</DataLocation> <DefaultData>AccountDefaultData</DefaultData> <IdLocation>^MyApp.AccountD</IdLocation> <IndexLocation>^MyApp.AccountI</IndexLocation> <StreamLocation>^MyApp.AccountS</StreamLocation> <Type>%Storage.Persistent</Type> } }
accéder à la publication Sylvain Guilbaud · Avr 8, 2024 As-tu le même problème depuis le portail d'administration ? Système > Classes
accéder à la publication Sylvain Guilbaud · Avr 8, 2024 Bonjour @Jean-Charles Cano peut-être que tu auras plus de détails en consultant la base de données d'AUDIT : Système > Gestion de la sécurité > Afficher la bdd d'audit Notamment sur des Événements d'audit système de type Protect
accéder à la publication Sylvain Guilbaud · Avr 8, 2024 IRIS (de même que Caché|Ensemble) permet en effet l'utilisation de jointures implicites (arrow syntax) en s'appuyant sur le dictionnaire unifié Objet/SQL des classes/tables définies dans ton modèle de données.Ceci offre l'avantage de simplifier l'écriture de requêtes SQL.
