1 TESTER OXYGENE SQL V2... 4

Oxyge ne SQL V2 Table des matières 1 TESTER OXYGENE SQL V2... 4 1.1 INSTALLER LE COMPOSANT D ACCES SQL... 4 1.2 INDIQUER L EMPLACEMENT DU SERVEUR... 4 1.3 LANCER L OPTION «TRANSFERT COMPLET DES DONNEES»... 4 1.4 DEFINIR LES DROITS UTILISATEURS SUR LES BASES CREEES... 5 2 OUTILS SQL SERVER... 6 2.1 OUTIL TRANSFERT COMPLET DES DONNEES... 6 2.1.1 Onglet de lancement du traitement... 6 2.1.2 Onglet Erreurs :... 7 2.1.3 Onglet Avertissements :... 8 2.1.4 Onglet Scripts SQL :... 9 2.2 CREATION DES BASES DE DONNEES... 9 2.2.1 Mode opératoire... 10 2.2.2 Description technique... 10 2.3 CREATION DES TABLES ET DES UTILISATEURS DANS SQL SERVER... 11 2.3.1 Mode opératoire... 11 2.3.2 Onglet Choix des tables... 11 2.3.3 Choix des utilisateurs... 12 2.3.4 Options de génération... 13 2.3.5 Génération du script... 14 2.3.6 Description technique... 15 2.4 TRANSFERT DES DONNEES... 15 2.4.1 Mode opératoire... 15 2.4.2 Choix des tables à transférer... 16 2.4.3 Transfert des tables... 17 2.4.4 Description technique... 18 2.5 LOCALISATION DES DONNEES... 18 2.5.1 Mode Opératoire... 18 2.5.2 Description Technique... 19 2.5.3 Option de localisation en ligne de commande... 19 3 EVOLUTIONS PAR RAPPORT A OXYGENE V1... 20 3.1 LISTE DES NOUVEAUTES... 20 3.1.1 Un cache en lecture... 20 3.1.2 Un cache en écriture... 20 3.1.3 La gestion des transactions... 21 3.1.4 L exécution de script... 21 3.1.5 L optimisation des éditions... 21 Memsoft le 26.09.2013 PAGE 1/42

3.2 NOUVELLES INSTRUCTIONS L4G... 22 3.2.1 ClasserPar... 22 3.2.2 EmpilerContexte... 22 3.2.3 DepilerContexte... 22 3.2.4 EstSQL (TABLE)... 22 3.2.5 CreerContexteMemoire... 22 3.2.6 BasculerContexteMemoire... 23 3.2.7 BasculerContexteDisque... 23 3.2.8 PeupleContexteMemoire... 23 3.2.9 CopierContexte... 23 3.2.10 Interface ::"INIT_INTERFACE"(1)... 24 3.2.11 ExecuteScriptSql... 24 3.2.12 ErreurScriptSQL... 24 3.2.13 TailleCacheLecture... 24 3.2.14 DetruireTableSQL... 25 3.2.15 EcrireCache... 25 3.2.16 ViderCache... 25 3.2.17 TailleCacheEcriture... 26 3.2.18 Timeout... 26 3.2.19 ModeVerrou... 26 3.2.20 Tables temporaires... 27 4 DESCRIPTIONS TECHNIQUES... 29 4.1 LA GESTION DES RESERVATIONS... 29 4.2 LES TRANSACTIONS... 29 4.3 LES TABLES MEMOIRES... 29 4.4 LES CONTEXTES MEMOIRE... 29 4.5 LA BASE OXYGENE... 29 4.6 TRANSFERT DE DONNEES... 29 4.7 SCRIPT SQL D ADAPTATION DE DOSSIER... 30 4.8 APPLIQUER LES CONTRAINTES SQL... 31 5 OPTIMISATION DU CODE POUR SQL SERVER... 32 5.1 OUTILS... 32 5.2 UTILISATION DE ESTSQL... 33 5.3 VERIFICATION DES INDEX... 33 5.4 OPTIMISATION DES PARCOURS ET ALGORITHMES... 35 5.4.1 Diagnostic... 35 5.4.2 Utilisation du cache en lecture et en écriture... 35 5.4.3 Utilisation des tables mémoires pour les calculs intermédiaires... 35 5.5 OPTIMISATION DE LST_SELECTION... 38 QUELQUES LIMITES DE CETTE VERSION... 40 QUE FAIRE SI OXYGENE REFUSE DE DEMARRER... 40 ANNEXE A : EXEMPLES... 41 Memsoft le 26.09.2013 PAGE 2/42

Memsoft le 26.09.2013 PAGE 3/42

1 Tester Oxygène SQL V2 1.1 Installer le composant d accès SQL Contacter le support technique Memsoft si vous avez besoin d une licence de test. 1.2 Indiquer l emplacement du serveur Si le serveur n est pas «(local)», Indiquer l emplacement de l instance SQL Server dans la ligne de commande Oxygène Exemple : SQL=NOMSERVEUR\SQLEXPRESS 1.3 Lancer l option «Transfert complet des données» Le menu des outils SQL Server contient une option de transfert complet des données. Cet outil permet d assister le consultant dans la migration des données chez le client. En effet toutes les étapes que nous avons vues précédemment seront réalisées par le même outil. Attention cet utilitaire transfert tous les dossiers d une même base de données. Une fois le transfert effectué Oxygène ++ sera redémarré en mode SQL. Il est alors possible de relocaliser les bases sur Oxygène avec l option «localisation des données» du menu des outils SQL. En cas de plantage au démarrage, il est possible d utiliser l option de ligne de commande /-R- qui permettra de ne pas démarrer les composants. Le transfert se déroulera comme suit : Oxygène ++ est basculé en mode exclusif et tous les objets en cours sont fermés. Si l utilisateur a choisi l option de correction des anomalies, l assistant supprimera les enregistrements en doublons (le premier sera gardé par défaut). Une Analyse du dictionnaire sera effectuée pour générer les scripts de créations des tables et des index. Si tout s est déroulé sans erreur le transfert des données s effectuera pour toutes les sociétés. Toutes les tables de la base de données seront localisées sur Microsoft SQL server. Seules les bases des applications et la base SYSTEME peuvent être transférées. La base $$ contenant le dictionnaire des données doit rester en base propriétaire. Memsoft le 26.09.2013 PAGE 4/42

1.4 Définir les droits utilisateurs sur les bases créées Tous les utilisateurs Windows qui se connectent à Oxygène doivent avoir des droits d accès sur les bases SQL Server. Cette fonctionnalité n a pas été intégrée à la migration car les utilisateurs Oxygène ne sont pas forcément les utilisateurs Windows sur le serveur. S il est possible de définir ces utilisateurs par l intermédiaire de l interface de SQL Server Management Studio, il est plus simple de créer un script SQL qui les définisse et qu on joue une fois après la migration pour chaque base créée sous SQL Server. Exemple : (Remplacer DEMO par le nom des vrais dossiers et répliquer pour chaque utilisateur) USE [GESCOM_DEMO] GO CREATE USER [MGESTION\rfroli] FOR LOGIN [MGESTION\rfroli] GO USE [GESCOM_DEMO] GO EXEC sp_addrolemember N'db_owner', N'MGESTION\rfroli' GO USE [OXYGENE_DEMO] GO CREATE USER [MGESTION\rfroli] FOR LOGIN [MGESTION\rfroli] GO USE [OXYGENE_DEMO] GO EXEC sp_addrolemember N'db_owner', N'MGESTION\rfroli' On crée un script de ce type pour chaque base et chaque utilisateur. On peut aussi créer ce script sous forme d un Script SQL d adaptation de dossier. Memsoft le 26.09.2013 PAGE 5/42

2 Outils SQL Server 2.1 Outil Transfert complet des données Cet outil permet d effectuer l ensemble de la migration des bases d une application en une seule manipulation : Création des bases OXYGENE (qui reçoit la base SYSTEME), de la base mono-société de l application (ex : GESCOM) et des bases multi-sociétés (ex : GESCOM_DEMO) Création de toutes les tables dans chaque base. Création des contraintes d intégrité référentielle si la case est cochée au niveau de la base de données (attention : nécessite des modifications de l application) Transfert de toutes les données. 2.1.1 Onglet de lancement du traitement Memsoft le 26.09.2013 PAGE 6/42

Base à transférer : Ce bouton permet de choisir la base de données que vous souhaitez transférer. Suppression des bases existantes : Si vous cochez cette case la base de données SQL SERVER correspondante à la société en cours de transfert sera supprimée, si elle existe. Corrections des anomalies : Cette option permet de corriger certaines anomalies que le moteur de vérification détectera. Le descripteur de données contient un outil qui permet d analyser les bases avant export. Cette option ne doit être activée que pour des tests car elle risque de supprimer des enregistrements utiles en production (par exemple des doublons sur la clé primaire ). Pour une migration réèlle il faut corriger les problèmes dans les données auparavant. Exporter les monnaies en EURO : Les valeurs des champs monnaie seront divisés par la valeur de la parité EURO / Franc (6.55957). Il faut ensuite aller modifier la monnaie de stockage au niveau de l assistant des monnaies (contacter le support Memsoft pour plus d information). Créer : Permet de lancer la création des bases de données et le transfert des données. 2.1.2 Onglet Erreurs : Cette liste affiche en fin de transfert la liste des anomalies qui ont empêché soit le transfert d une base de données soit le transfert d une table. Le résultat du transfert s affiche dans le champ «Résultat transfert». Memsoft le 26.09.2013 PAGE 7/42

Une jauge indique la progression du transfert pour chaque table. Exporter : Permet d exporter la liste des erreurs dans le tableur Excel. 2.1.3 Onglet Avertissements : Cette liste affiche en fin de transfert la liste des anomalies qui ont été détectées mais qui n ont pas empêché le transfert de la base de données ou d une table. Le résultat du transfert s affiche dans le champ «Résultat transfert». Exporter : Permet d exporter la liste des avertissements dans le tableur Excel. Memsoft le 26.09.2013 PAGE 8/42

2.1.4 Onglet Scripts SQL : En fin de transfert l assistant affiche les scripts utilisés pour la création des bases de données. Exporter : Permet d enregistrer dans un fichier le script SQL concerné. 2.2 Création des bases de données Cette opération s effectue avec l utilitaire «création de bases». Il permet de définir les caractéristiques des bases de données et de générer le script correspondant. Ce script est ensuite directement exécuté par MICROSOFT SQL Server pour la création des bases. Il est possible de sauvegarder (exporter) un script ou d en importer un pour l exécuter. Memsoft le 26.09.2013 PAGE 9/42

2.2.1 Mode opératoire Après avoir choisi l instance MICROSOFT SQL Server sur laquelle vous souhaitez créer la base de données, vous devez indiquer la base de données et le dossier pour que la base [BASE]_[DOSSIER] soit créée. Pour générer le script de création cliquez sur le bouton «Générer». Pour exécuter le script et créer la base de données cliquez sur le bouton «Créer». Si vous souhaitez enregistrer le script vous devez cliquer sur le bouton «Exporter». Si vous souhaitez utiliser un script existant vous pouvez l importer grâce au bouton «Importer». 2.2.2 Description technique Cet utilitaire est géré par l objet CREER_BASE (creerbas.l4g) du composant SQLTOOLS. Il fait appel à la méthode «CREATION_BASE» du composant SQLSCRIPT. Memsoft le 26.09.2013 PAGE 10/42

2.3 Création des tables et des utilisateurs dans SQL SERVER Une fois votre base créée sur MICROSOFT SQL Server il faut créer les tables et leurs utilisateurs. Un assistant est à votre disposition qui vous permet de choisir les tables à transférer, les utilisateurs, les options de génération et de générer et exécuter le script de création des tables. 2.3.1 Mode opératoire Une fois votre base créée sur MICROSOFT SQL Server il faut créer les tables et leurs utilisateurs. Un assistant est à votre disposition qui vous permet de choisir: les tables à transférer, les utilisateurs, les options de génération, et de générer le script de création des tables. Les deux premiers onglets permettent choisir les tables et les utilisateurs que l on souhaite créer dans MICROSOFT SQL Server. 2.3.2 Onglet Choix des tables Cet onglet permet de choisir les tables à créer Memsoft le 26.09.2013 PAGE 11/42

Base Oxygène ++ : Ce bouton permet de choisir la base pour laquelle vous souhaitez créer les tables. Une fois le choix de la base effectué la liste des «tables disponibles» est renseignée avec la totalité de ses tables. Société à Transférer : Ce bouton vous permet de choisir la société pour laquelle vous souhaitez créer les tables. MULTI /MONO dossier : Ce bouton radio permet de choisir la nature des tables, communes ou non à toutes les sociétés. Le changement d état de ce bouton efface la liste des tables retenues. Les boutons de choix des tables : Il permet de choisir une table, elle apparaitra dans la liste des tables retenues. Il permet d enlever une table, elle disparaitra de la liste des tables retenues. Il permet de choisir toutes les tables, elles apparaitront dans la liste des tables retenues. Il permet d enlever toutes les tables, elles disparaitront de la liste des tables retenues. 2.3.3 Choix des utilisateurs Cet onglet permet de choisir les utilisateurs à créer Memsoft le 26.09.2013 PAGE 12/42

Les boutons de choix des utilisateurs : Il permet de choisir un utilisateur, il apparaitra dans la liste des utilisateurs retenus. Il permet d enlever un utilisateur, il disparaitra de la liste des utilisateurs retenus. 2.3.4 Options de génération MS SQL Server : Cet onglet permet de choisir les options de génération Ces zones sont renseignées par l option de la ligne de commande /SQL=[SERVER]. Si le serveur SQL possède un nom d instance (ex : SRVTOTO/OXYGENESQL), le nom d instance (OXYGENESQL) sera supprimé et les noms d utilisateurs seront préfixés du nom du serveur (SRVTOTO dans cet exemple). Choix du nom de domaine : Permet de créer les connexions utilisateurs et les droits sur les tables à partir d utilisateurs du DOMAINE. Rempli par défaut par le nom du serveur. Structure des tables : Memsoft le 26.09.2013 PAGE 13/42

Structures de tables permet la création des tables. Cochez cette case pour créer des tables dans MICROSOFT SQL Server. Création d index : Cette option est fortement conseillée, elle permet l optimisation des temps de traitements de vos tables. Les index créés dépendent des choix d index faits pour la base OXYGENE++ Forcer la création : Permet d effacer les structures de tables pouvant déjà exister sur MICROSOFT SQL Server et de les remplacer. Cette option écrase les données si celles-ci ont été créées. Création des utilisateurs : Cocher cette case pour créer dans MICROSOFT SQL Server les utilisateurs OXYGENE++ sélectionnés dans l onglet précédent comme étant des utilisateurs des tables choisies dans le premier onglet. Dans le cas de bases importantes il est conseillé de procéder en trois étapes (trois scripts) : la création des structures de tables la création des index ; la création des utilisateurs. 2.3.5 Génération du script Memsoft le 26.09.2013 PAGE 14/42

Cet onglet permet de générer et d exécuter le script Importer : Ce bouton permet d importer un script et de l exécuter. Exporter : Ce bouton permet d enregistrer le script dans un fichier.sql. Générer : Ce bouton permet de lancer la génération du script de création. Créer : Ce bouton permet de lancer l exécution du script. Si des anomalies sont détectées elles seront affichées dans la zone de compte rendu en bas de l écran. 2.3.6 Description technique Cet assistant est géré par l objet SCRIPTE_TABLE (creertab.l4g) du composant SQLTOOLS. La génération du script de création des utilisateurs se fait grâce aux méthodes «CREATION_LOGIN» du composant SQLSCRIPT. La génération du script de création des tables se fait grâce à la méthode «CREATION_TABLE» du composant SQLSCRIPT. 2.4 Transfert des données Cet outil OXYGENE++ permet de transférer les données OXYGENE++ vers MICROSOFT SQL Server en procédant à une réplication des tables que vous aurez choisies dans l assistant de transfert de données. Attention, cet outil ne permet le transfert de données que dans un sens : depuis la base OXYGENE++vers la base Microsoft SQL Server. 2.4.1 Mode opératoire Attention, La table dans la base de données est supprimée avant le transfert. Memsoft le 26.09.2013 PAGE 15/42

2.4.2 Choix des tables à transférer Base Oxygène ++ : Ce bouton permet de choisir la base pour laquelle vous souhaitez transférer les tables. Une fois le choix de la base effectué la liste des «tables disponibles» est renseignée avec la totalité de ses tables. Société à Transférer : Ce bouton vous permet de choisir la société pour laquelle vous souhaitez transférer les tables. MULTI /MONO dossier : Ce bouton radio permet de choisir la nature des tables, communes ou non à toutes les sociétés. Le changement d état de ce bouton efface la liste des tables retenues. Les boutons de choix des tables : Il permet de choisir une table, elle apparaitra dans la liste des tables retenues. Il permet d enlever une table, elle disparaitra de la liste des tables retenues. Il permet de choisir toutes les tables, elles apparaitront dans la liste des tables retenues. Il permet d enlever toutes les tables, elles disparaitront de la liste des tables retenues. Memsoft le 26.09.2013 PAGE 16/42

2.4.3 Transfert des tables Transférer : Ce bouton permet de lancer le transfert des données. Données à transférer : Cette liste affiche en début de transfert la liste des tables à transférer Le résultat du transfert s affiche dans le champ «Résultat transfert». Une jauge indique la progression du transfert pour chaque table. Pour effectuer le transfert, il est nécessaire que les tables soient localisées sur la base Oxygène++. Si vous vous rendez compte que, quelle que soit la table transférée, le résultat est «Table vide :NON transférée» c est probablement que votre base est localisée sur MICROSOFT SQL Server et non sur Oxygène++. Reportez-vous au chapitre «Localisation des données» pour changer sa localisation. Memsoft le 26.09.2013 PAGE 17/42

2.4.4 Description technique Cet assistant est géré par l objet TRANSFERT_DATA (trandata.l4g). Pour chaque table notée dans la liste des données à transférer cet objet appel la méthode «REMPLIT_UNE_TABLE» du composant SQLTOOLS. 2.5 Localisation des données Il faut spécifier à OXYGENE++ sur quelle base de données (OXYGENE++ ou MICROSOFT SQL Server) vous voulez travailler. L opération est réversible, vous pouvez revenir sur OXYGENE++ après avoir travaillé sur MICROSOFT SQL Server. Attention tout de même, des données créées ou modifiées sur SQL Server ne seront pas sur la base de données d OXYGENE++ et réciproquement. Cette opération ne concerne que la localisation des données et non le transfert réel des données. Les modifications effectuées sur les données de la base MICROSOFT SQL Server ne sont pas reportées dans la base de données OXYGENE++ et réciproquement. La localisation de données est totalement indépendante du transfert de données. Elle ne dispense en rien de cette étape. Lorsque vous localisez la gestion commerciale (ou tout autre base de données) d'un de vos dossier sur MICROSOFT SQL Server, la gestion commerciale sera localisée sur MICROSOFT SQL Server pour tous les autres dossiers aussi. Pensez à transférer les données pour tous vos dossiers. 2.5.1 Mode Opératoire Memsoft le 26.09.2013 PAGE 18/42

Base de données : Vous permet de choisir la base de données pour laquelle vous souhaitez changer la localisation. Oxygène ++ vers MS SQL Server : Cette option va localiser toutes les tables de votre base de données sur MS SQL server. MS SQL Server vers Oxygène ++: Cette option va localiser toutes les tables de votre base de données sur Oxygène ++. 2.5.2 Description Technique Cet assistant est géré par l objet SQLCONV (creerbas.l4g) du composant SQLTOOLS. Il change la localisation de toutes les tables de la base, sans convertir les données. Pendant la phase de migration et de mise au point il permet des aller-retours entre la base propriétaire et la base SQL server, pour par exemple comparer des temps de traitement ou autres. 2.5.3 Option de localisation en ligne de commande Une option permettant de forcer la localisation de la base SYSTEME au démarrage est disponible sous la forme d une option de ligne de commande /DB_LOC=mhi Relocalise la base système en base propriétaire /DB_LOC=sql Relocalise la base système en base SQL Server Cette option permet de redémarrer oxygène quand celui-ci ne veut plus redémarrer après la conversion des données de la base système. On peut alors démarrer Oxygène en mode /-R-, sans les composants, et dépanner. Comme pour la localisation, cette option ne convertit aucunement les données. Memsoft le 26.09.2013 PAGE 19/42

3 Evolutions par rapport à Oxygène V1 Nous avons fusionné les sources des deux composants BDOLEDB d Oxygène SQL et du composant d accès SQL. Cette fusion, en plus du pool de sessions et du dictionnaire des tables nous a permis de bénéficier des fonctionnalités décrites ci-dessous. 3.1 Liste des nouveautés 3.1.1 Un cache en lecture Nous avons reporté dans le L4G la fonctionnalité TailleCacheLecture afin de récupérer plusieurs lignes avec une seule requête. Si table est une table séquentielle indexée cette fonctionnalité ne change rien, par contre si c est une table SQL toutes les lignes demandées sont rapatriées sur le poste client. Cette fonctionnalité permet d accélérer toutes les boucles sur une table, l affichage et le chargement d un document géré par le modèle SDOCUM. Par contre le cache en lecture ne fonctionnait pas correctement avec une liste : nous avons corrigé ce problème pour SQL 2005. 3.1.2 Un cache en écriture Pour réduire le coût des échanges entre Oxygène et SQL Server lors d insertions de nombreux enregistrements à la suite, on peut utiliser une fonction d écriture bufférisée qui utilise un cache en écriture. Le cache se présente sous la forme d un tableau de gros buffers dans lesquels les instructions («INSERT INTO») sont concaténées séquentiellement. Quand le tableau est plein (ou à la demande du développeur) l ensemble des commande est envoyé à SQL server (un appel OLEDB par case du tableau). Par défaut le tableau contient 10 cases de 20000 caractères (valeurs actuellement non modifiable). Si on prend l exemple de l insertion dans une table qui générerait une requête «INSERT INTO» de 1000 caractères, l insertion massive d enregistrement dans cette table génèrera séquences de 10 commandes OLEDB contenant 20000/1000 = 20 "INSERT INTO". Le nombre et la taille de buffers du tableau sera peut-être rendu paramétrable dans une future version. Memsoft le 26.09.2013 PAGE 20/42

3.1.3 La gestion des transactions Nous avons reporté dans le L4G toutes les instructions qui concernent les transactions. Comme pour le cache en lecture, elles sont inactives avec la base de données Oxygène. 3.1.4 L exécution de script L instruction ExecuteScriptSql et dorénavant disponible dans le L4G, ce qui permet d exécuter des requêtes spécifiques (ou d appeler des procédures stockées) lorsque la base de données est hébergée par SQL SERVER. 3.1.5 L optimisation des éditions Ajout de cache en lecture dans les modèles d impression de base (impetat) Possibilité de charger en mémoire les tables en lien Memsoft le 26.09.2013 PAGE 21/42

3.2 Nouvelles instructions L4G 3.2.1 ClasserPar Permet de choisir un ordre de classement sur une table Syntaxe : ClasserPar(<code de table>) = vclassement Le classement choisi peut porter sur plusieurs colonnes en précisant éventuellement l ordre de parcours sur chaque colonne. La syntaxe à utiliser est celle des paramètres de la clause Order By du langage SQL. Exemple : ClasserPar(GCPLFAC)= "GCPARTIC_CODE,-HT" Classe par GCPARTIC_CODE croissant et par HT décroissant. 3.2.2 EmpilerContexte Permet de sauvegarder le contexte d utilisation d une table : filtres, classement, position courante Syntaxe : EmpilerContexte <code de table> Cette instruction ne peut pas être imbriquée. Il faut appeler systématiquement DepilerContexte. Voir DepilerContexte. 3.2.3 DepilerContexte Permet de restaurer le contexte d utilisation d une table (filtres, classement, position courante) précédemment sauvegardé par EmpilerContexte Syntaxe : DepilerContexte <code de table> 3.2.4 EstSQL (TABLE) Dans certains cas nous ne pouvons pas utiliser le même algorithme, il est donc nécessaire de détecter dans le L4G quelle est la nature de la table qui est utilisée. Cette fonction retourne 1 si la table est SQL, 0 dans le cas contraire. 3.2.5 CreerContexteMemoire Crée un contexte mémoire au niveau d une table. Memsoft le 26.09.2013 PAGE 22/42

3.2.6 BasculerContexteMemoire Force la table à travailler sur son contexte mémoire. Le contexte mémoire doit avoir été créé auparavant par CreerContexteMemoire. 3.2.7 BasculerContexteDisque Force la table à travailler sur son contexte disque. 3.2.8 PeupleContexteMemoire Cette instruction permet de peupler directement un contexte mémoire avec le résultat d une requête. Elle prend en paramètres le nom de la table concernée et le nom d une méthode à appeler pour chaque enregistrement. Elle fonctionne quelle que soit la nature de la table sous-jacente. Exemple : Methode "EXTRACTION_LIGNE" Nb_Enregs = Nb_Enregs +1 FinMethode // remplit le contexte mémoire avec les données de la table "MATABLE" Methode "BASCULER_MATABLE" CreerContexteMemoire(MATABLE) PeupleContexteMemoire MATABLE, "EXTRACTION_LIGNE" BasculerContexteMemoire(MATABLE) FinMethode Le travail sur la table chargée en mémoire est ensuite particulièrement rapide puisqu il ne nécessite plus d appel à la base SQL. La table MA_TABLE peut bien entendu être une vue. 3.2.9 CopierContexte Copie l enregistrement courant d un contexte vers l autre (du contexte disque vers le contexte mémoire si la table est en contexte disque et vice versa). Exemple : // recopie le contexte mémoire de la table "MATABLE" sur disque Methode "SERIALISER_MATABLE" TantQue LireSuivant(MATABLE) Alors CopierContexte(MATABLE) FinTantQue BasculerContexteDisque(MATABLE) FinMethode Memsoft le 26.09.2013 PAGE 23/42

3.2.10 Interface :: "INIT_INTERFACE"(1) Deux méthodes ont été ajoutées au modèle interface pour gérer la mise en mémoire des tables. L objectif est surtout d optimiser la recherche des champs en lien dans les tables ayant une taille limitée (articles, adresses). Pour plus de sécurité on peut vérifier l emprise de la table une fois chargée en mémoire en multipliant la taille d un enregistrement par le nombre d enregistrement maximum envisagé. Il ne faut pas non plus que le temps de chargement de la table en mémoire soit plus long que le gain réel de l optimisation. Si cette optimisation peut être intéressante dans les impressions, elle est plus discutable pour des modèle accès. AppliquerMethodeComposant "COMPOSANT"."INIT_INTERFACE"(1) Il faut refaire une lecture après l appel à INIT_INTERFACE"(1) car la fonction ne recharge pas les enregistrements. 3.2.11 ExecuteScriptSql Permet d exécuter des requêtes ou d appeler des procédures stockées. Exemple : // On teste l'existence de la procédures stockées. Script = "IF (OBJECT_ID('sp_test','P') IS NULL) SELECT 1 ELSE SELECT 0" Err = ExecuteScriptSQL (VBASE, v_societe, Script, Retour) Si Retour = "0" Alors Script = "EXEC sp_test" Err = ExecuteScriptSQL (VBASE, v_societe, Script, Retour) FinSi Si la requête ou la procédure ne retourne rien, ne pas passer le paramètre «Retour» sinon un message d erreur sera affiché. 3.2.12 ErreurScriptSQL Variable système en lecture seule qui contient le code d erreur de la dernière instruction ExecuteScriptSQL exécutée. 3.2.13 TailleCacheLecture Cette fonction permet d optimiser les lectures sequentielles sur lesquelles aucun filtre particulier n est posé. Ces lectures se caractérisent par une succession de «SELECT TOP 1...» sur la même table. En forçant la taille du cache de lecture, les enregistrements seront lus par bloc. Exemple : // lire la table par bloc de 100. Memsoft le 26.09.2013 PAGE 24/42

TailleCacheLecture (TABLE) = 100 Cette fonction ne doit être utilisée que pour les phases de lecture. Si la table est modifiée, il faut ensuite réinitialiser la table par TailleCacheLecture (TABLE) = -1 3.2.14 DetruireTableSQL Detruit physiquement une table SQL 3.2.15 EcrireCache Ecrit un enregistrement dans le cache en écriture. S utilise à la place de l instruction "Ecrire" pour écrire un nouvel enregistrement dans le cache en écriture. Dès que le cache est plein, celui-ci est automatiquement «vidé» par l envoi des instructions à SQL Server. A la fin de la série d écriture, le cache doit être vidé par un appel à «ViderCache». Exemple : Methode FAIRE Variables : Entier i Pour i=0; i<100 Faire Num = i EcrireCache TABLE FinPour ViderCache TABLE FinMethode Des erreurs peuvent être détectées lors de la phase d écriture sur le disque. Il est donc recommandé d encadrer l ensemble des écritures par une transaction. Au contraire de la fonction "Ecrire", la fonction "EcrireCache" ne vérifie pas si la table est déjà réservée, ceci dans un but d optimisation. Le développeur doit donc le vérifier en utilisant l instruction "EtatTable". 3.2.16 ViderCache Force l écriture du cache en écriture sur le disque S utilise pour terminer une opération d écriture d enregistrements effectuée à l aide de l instruction "EcrireCache". Exemple : Methode FAIRE Memsoft le 26.09.2013 PAGE 25/42

Variables : Entier i Pour i=0; i<100 Faire Num = i EcrireCache TABLE FinPour ViderCache TABLE FinMethode 3.2.17 TailleCacheEcriture Interroge la quantité de données présente dans le cache en écriture pour une table donnée. Cette variable peut seulement être lue. Elle s utilise conjointement avec les instructions "EcrireCache" et "ViderCache". La taille du cache est exprimée en octets. Elle représente la taille du cache en écriture effectivement utilisé. Elle est donc remise à zéro par l instruction "ViderCache". Exemple : vtaillecache = TailleCacheLecture (TABLE) 3.2.18 Timeout Définition du délai d expiration (TimeOut) des requêtes OLEDB. Dans le cas de gros volume de données, le temps d exécution des requêtes peut dépasser le Timeout par défaut défini dans Oxygène, qui est de 5 secondes. Il est possible de définir la valeur de ce Timeout table par table. Exemple : Methode Init AppliquerDefaut Timeout(TABLE)=30 FinMethode Par expérience, les volumes «normaux» pouvant générer des Timeout sont en général de plusieurs centaine de milliers d enregistrements. En deçà, il faut plutôt d examiner la pertinence des index 3.2.19 ModeVerrou Permet de lire ou d écrire le mode de verrouillage utilisé sur les lectures d une table. Notes : Les valeurs utilisables pour vmode sont parmi les valeurs suivantes : NOLOCK Memsoft le 26.09.2013 PAGE 26/42

ROWLOCK PAGLOCK TABLOCK TABLOCKX HOLDLOCK UPDLOCK XLOCK READUNCOMMITTED READCOMMITTED REPEATABLEREAD SERIALIZABLE Dans certains cas, on pourra utiliser une combinaison de ces valeurs. Par exemple : ROWLOCK,UPDLOCK Pour de plus amples informations concernant l utilisation de cette fonction, consulter la documentation en ligne de Microsoft SQL Server à la rubrique «Indicateurs de verrouillage». Exemple : ModeVerrou(TABLE)="ROWLOCK, UPDLOCK" modecour = ModeVerrou(TABLE) 3.2.20 Tables temporaires Il est possible de manipuler un objet table dont les données sont situées dans la base «tempdb» de SQL Server. Cela permet d effectuer par exemple des opérations sans aller-retour entre le client et le serveur, dont les résultats s enregistrent dans une tablez temporaire. Il n y a plus qu à lire les résultats. Il faut activer ce mode dans la déclaration de la table en utilisant le préfixe «SQL :TEMPDB :» dans la déclaration de la table. La syntaxe est la suivante : TABLE_SECONDAIRE : "SQL:TEMPDB:MATABLE"->"TEMP_MATABLE" Exemple Objet TRAITEMENT : TEST_TEMPDB Declaration TABLE_SECONDAIRE : "SQL:TEMPDB:TB_VAL"->"TEMP_VAL" TABLE_SECONDAIRE : ptable->"temp_val2" FinDeclaration Methode INIT NomBase TEMP_VAL, "SYSTEME" Memsoft le 26.09.2013 PAGE 27/42

NomTable TEMP_VAL2, "SQL:TEMPDB:##MEM#SYSTEME#DOSSIER#TB_VAL#" AppliquerDefaut FinMethode Methode DEBUT FinMethode AppliquerMethode UtiliserTableTemporaireOxygene AppliquerMethode UtiliserTableTemporaireExterne // créer et utiliser une tabletemporaire dans TempDB Methode UtiliserTableTemporaireOxygene Variables: Chaine Script Entier Err // crée la table dans TempDB LirePremier(TEMP_VAL) // appelle une requete qui remplit la table TB_VAL de tempdb // la première ligne permet de substitue la propriété IDENTITY Script="SET IDENTITY_INSERT [dbo]." + NomTableSQL(TEMP_VAL) + " ON;"+ SautDeLigne + "GO" + SautDeLigne + "INSERT INTO [dbo].[" + NomTableSQL(TEMP_VAL) + "]" + SautDeLigne + "(OX_COMPTEUR,ANNEEMOIS,CODE,VALEUR1,VALEUR2, VALEUR3,TEXTE)" + SautDeLigne + "SELECT * from [OXYGENE_DEMO].[dbo].[TB_VAL]" + SautDeLigne + "WHERE [ANNEEMOIS] >= '2011' AND [ANNEEMOIS] < '2012'" + SautDeLigne + "GO" + SautDeLigne + "SET IDENTITY_INSERT [dbo]." + NomTableSQL(TEMP_VAL) + " OFF;" + SautDeLigne + "GO" + SautDeLigne Err = ExecuteScriptSQL ("tempdb", "", Script) PositionnerDebut(TEMP_VAL) TantQue LireSuivant (TEMP_VAL) BoiteMessage TEMP_VAL.CODE + TEMP_VAL.VALEUR1 FinTantQue FinMethode // utiliser une tabletemporaire dans TempDB déjà créée Methode UtiliserTableTemporaireExterne Variables: Chaine Script Entier Err Script="SET IDENTITY_INSERT [dbo].[##mem#systeme#dossier#tb_val#] ON;"+SautDeLigne+ "GO" + SautDeLigne + "INSERT INTO [dbo].[##mem#systeme#dossier#tb_val#]" + SautDeLigne + "(OX_COMPTEUR,ANNEEMOIS,CODE,VALEUR1,VALEUR2, VALEUR3,TEXTE)" + SautDeLigne + "SELECT * from [OXYGENE_DEMO].[dbo].[TB_VAL]" + SautDeLigne + "WHERE [ANNEEMOIS] >= '2011' AND [ANNEEMOIS] < '2012'" + SautDeLigne + "GO" + SautDeLigne + "SET IDENTITY_INSERT [dbo].[##mem#systeme#dossier#tb_val#] OFF;" + SautDeLigne + "GO" + SautDeLigne Err = ExecuteScriptSQL ("tempdb", "", Script) PositionnerDebut(TEMP_VAL2) TantQue LireSuivant (TEMP_VAL2) BoiteMessage TEMP_VAL2.CODE + TEMP_VAL2.VALEUR1 FinTantQue FinMethode FinObjet Memsoft le 26.09.2013 PAGE 28/42

4 Descriptions techniques 4.1 La gestion des réservations Sur ce point nous avons dû revoir de fond en comble la gestion des réservations, en effet celle qui était implémentée dans le composant d accès SQL était trop lente, et celle d Oxygène SQL utilisait les verrous. 4.2 Les transactions Oxygène SQL gère le mécanisme des transactions qui permet, si un traitement de mise à jour ne s effectue pas correctement, d annuler tout ce qui à été fait depuis le début de la transaction. Prenons un exemple lors de la transformation d un document de vente si un incident arrive en base de données propriétaire la table des lignes et celle des chainages peuvent être dans un état incorrect. Si on démarre une transaction au début de la transformation et que celle-ci échoue toute les modifications apportées seront automatiquement annulées par SQL SERVER. Dans Oxygène SQL nous disposons des instructions DebuterTransaction, ValiderTransaction, AnnulerTransaction et TransmetTransaction pour gérer par programmation L4G les transactions. 4.3 Les tables mémoires Nous avons gardé le principe des tables en mémoire vive. Il est possible de déclarer des tables dans tempdb avec un préfixe sur e nom de table. 4.4 Les contextes mémoire Nous avons aussi gardé le principe des contextes mémoire afin de ne pas modifier le modèle SDOCUM et en conséquence de garder une compatibilité avec les objets qui l utilisent. 4.5 La base Oxygène Le serveur SQL doit obligatoirement contenir une base de données nommée OXYGENE. La table des réservations est créée automatiquement dans cette base, et des erreurs surviennent si elle n existe pas. Cette base est normalement créée automatiquement par le transfert total des données. Si le transfert total n est pas utilisé, il faut la créer à la main. 4.6 Transfert de données Le transfert de données, qui passe par des instructions SQL INSERT unitaire n est pas très efficace. En attendant une amélioration de ces performances, il pourrait être intéressant d explorer d autres pistes côté SQL pour accélérer les insertions d enregistrement «en masse». Par exemple enlever les index avant l insertion puis les remettre après (les enregistrements de la base oxygène sont insérés dans l ordre). Memsoft le 26.09.2013 PAGE 29/42

Il semble qu il est aussi possible d importer des données en bloc à l aide de BULK INSERT à partir d un fichier (un export de la base Oxygène dans notre cas) http://msdn.microsoft.com/fr-fr/library/ms175915.aspx 4.7 Script SQL d adaptation de dossier Des fichiers SQL peuvent être placés sous «[OXYPP]/systeme/sql». Ils seront exécutés à chaque nouvelle création de base (dossier). La syntaxe du nom de ces fichiers est [NOMBASE]_DOSSIER_[VERSION].sql Exemple : GESCOM_DOSSIER_10000001.sql -- Base GESCOM USE [GESCOM_<SOCIETE>] GO -- Table [VERSION] CREATE NONCLUSTERED INDEX [IDX_GCPEBL_QTNT] ON [dbo].[gcpebl] ( La balise <SOCIETE> sera remplacée par le nom de la société à l exécution du script. Dans chaque base il existe une table VERSION Quand un script est exécuté, un enregistrement est ajouté automatiquement à la table avec le n de version et la date d execution. Lors d une mise à jour de dossier, seuls les scripts dont le n de version est supérieur au numero de version indiqué dans la table seront joués. A la création du dossier, tous les scripts seront joués. Il est recommandé que les scripts soient écrits de manière à pouvoir être joués plusieurs fois sur la même base sans provoquer des erreurs, par l utilisation de tests (if exists ) Memsoft le 26.09.2013 PAGE 30/42

4.8 Appliquer les contraintes SQL Cette option très intéressante permet de créer des clés externes (Foreign keys) entre les tables SQL Server. Les clés étrangères assurent la cohérence de la base même en cas d'erreur de programmation, plante ou autre. Elle nécessite un travail supplémentaire lors de la migration : 1 - modification du code principalement lors des suppressions (il faut supprimer dans le bon ordre) 2 - correction de la base avant export : toutes les clés externes doivent être renseignées avant migration. L'outil "Analyse des clés primaires et étrangères" dans le descripteur de données permet un diagnostic de ce point. Il est bien sûr plus facile de mettre en place ces contraintes lors d'une nouvelle installation que lors d'une mise à jour. L option «Appliquer les contraintes SQL" peut être modifiée dans l'écran de gestion d'une base Oxygène. Memsoft le 26.09.2013 PAGE 31/42

5 Optimisation du code pour SQL Server 5.1 Outils Quand on veut améliorer les performances de certains traitements, le premier outil à utiliser est souvent SQL Server Profiler. En regardant la colonne «durée», on repère les requêtes longues qui pourraient être optimisées. L image ci-dessous montre par exemple une requête sur les bons de livraisons, avec un filtre sur le type, qui provoquait un «TimeOut», matérialisé par une erreur dans Oxygène. La cause de l erreur était très visible dans le profiler. Il n existait pas d index sur le champ du filtre, et la requête était anormalement longue. En sélectionnant les filtres à appliquer, on ne voit passer que les requêtes Oxygène. Memsoft le 26.09.2013 PAGE 32/42

5.2 Utilisation de EstSQL La fonction EstSQL permet de faire exécuter du code uniquement quand la table est localisée sur SQL Server. Bien que ça ne soit pas indispensable, il peut être intéressant de développer quelques parties de code spécifique SQL si certains traitements s avèrent trop longs. Il peut aussi être utile d ajouter des index sur des champs sur lesquels des filtres sont faits, alors qu ils n étaient pas indispensables en base propriétaire. 5.3 Vérification des index Comme le montre l exemple précédent, l absence d index sur les critères de certains filtres peut se révéler pénalisant sur des gros volumes sous SQL Server. En cas de problèmes de performances sur certaines requêtes, il faut donc vérifier l utilisation des index, par exemple en utilisant le plan d exécution. Dans l exemple de l index manquant, la requête filtrait sur le champ QTNT : Select top 1 * from dbo.[gcpebl] WHERE (QTNT<>0) ORDER BY OX_COMPTEUR ASC Memsoft le 26.09.2013 PAGE 33/42

En rejouer requête dans Management Studio, le temps d exécution était > 1 mn. Oxygène plantait donc, en TimeOut sur cette requête. En regardant la table des BL avec le descripteur d objet, on pouvait voir qu l n y avait aucun index sur le champ QTNT Ceci pouvait se vérifier dans le plan d exécution, qui montrait que seul l index principal (cluster) était utilisé, avec un nombre d exécutions énorme. On a donc créé un index sur les champs OX_COMPTEUR / QTNT en vérifiant qu il soit bien utilisé (dans le plan d exécution). L image ci-dessous illustre l utilisation de ce nouvel index, et montre que le «number of exécutions» de l index cluster principal est tombé à 1 Le résultat est éloquent, puisque le temps d exécution est passé à moins d 1 sec, et que le plantage a donc disparu. Memsoft le 26.09.2013 PAGE 34/42

Si on ne veut pas ou si on n a pas la possibilité d ajouter ajouter ces index dans la version propriétaire avant migration, on peut toujours les ajouter dans un fichier SQL de «script d adaptation de dossier» (voir plus loin). Exemple pour l index ci-dessus CREATE NONCLUSTERED INDEX [IDX_GCPEBL_QTNT] ON [dbo].[gcpebl] ( [OX_COMPTEUR] ASC, [QTNT] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 5.4 Optimisation des parcours et algorithmes 5.4.1 Diagnostic Si certains modèles ont été optimisés pour SLQ Server, comme le modèle document, import ou Edition, les parcours n ont pas été spécialement optimisés car ils peuvent être utilisés de différentes manières, et surtout alterner lecture et écriture. Tous les traitements ne nécessitent pas des performances exceptionnelles, mais nombres d impression statistiques ou autres traitements qui parcourent par exemple l ensemble des factures ne sont pas traitées efficacement car Oxygène travaille par défaut avec des curseurs, lisant les enregistrements un par un lors d un parcours. Quand on repère un problème de performance, on peut utiliser SQL Server Profiler pour contrôler le nombre de requêtes unitaires qui sont envoyées au serveur. Un trop grand nombre de requêtes de type «SELECT TOP 1» est souvent signe de mauvaises performances. 5.4.2 Utilisation du cache en lecture et en écriture 5.4.3 Utilisation des tables mémoires pour les calculs intermédiaires L exemple suivant présente un calcul du palmarès des ventes par article pour un client. Le traitement n est pas très optimisé pour SQL Server : - On crée le palmarès dans une table disque, ce qui génère de nombreuses écritures vers la base - On parcourt toutes les lignes, sans filtre, et on teste pour chaque ligne le client associé à l entête. - Pour chaque ligne qui correspond on lit le code dépôt associé par l interface GCPDEPOT Memsoft le 26.09.2013 PAGE 35/42

Pour SQL Server, on va donc avoir pour chaque ligne de facture Un select sur la ligne Un select sur l entête Si le code client est le bon un select sur le dépôt un insert sur la table VISUPIEC Exemple: pour 10 000 factures de 10 lignes dont 100 concernent le client nous aurons 2*100000 + 2 * 1000 = 202000 requêtes Le premier exemple d optimisation ne touche pas l algorithme, mais utilise les caches en lecture et travaille sur des tables mémoires. Le choix des optimisations dépend du contexte. Objet TRAITEMENT : VISU_PIECES Declaration // la table VISUPIEC n'est utilisée que dans ce traitement -> on la met en memoire // TABLE : "VISUPIEC" -> VISUPIEC TABLE : "MEM:VISUPIEC" -> VISUPIEC TABLE_SECONDAIRE: CTX_ENTETE TABLE_SECONDAIRE: CTX_LIGNE FinDeclaration PARAMETRES : Chaine VIDCLI Methode "DEBUT" Variables : Chaine vtemp AppliquerDefaut Supprimer VISUPIEC // Demander à l'interface de travailler en table memoire (interessant car peu de dépots) // provoque le chargement de la table complète en mémoire AppliquerMethodeComposant "GCPDEPOT"."BASCULERCONTEXTEMEMOIRE" // La lecture étant séquentielle, on lit les lignes et entêtes par bloc TailleCacheLecture(CTX_LIGNE) = 1000 TailleCacheLecture(CTX_ENTETE) = 1000 DebutRequete CTX_LIGNE Filtre(CTX_LIGNE.GCPARTIC_CODE,DifferentDe,"") PositionDebut FinRequete TantQue LireSuivant(CTX_LIGNE) // extraction ident de entête vtemp= Gauche(CTX_LIGNE.NUMERO,Position(" ",CTX_LIGNE.NUMERO)-1) // Lire l'entête de la ligne courante Si Lire(CTX_ENTETE.IDENT,EgalA,vtemp) Alors // teste sur le client client Si CTX_ENTETE.GCPCLI_IDENT = VIDCLI Alors // cumuls pour le palmares VISUPIEC.PU_NET = CTX_LIGNE.HT/CTX_LIGNE.QTE VISUPIEC.QTNT = CTX_LIGNE.QTE-CTX_LIGNE.QTT (...) VISUPIEC.CLIART_DESIG = CTX_LIGNE.DESIG // lecture du code du depot AppliquerMethodeComposantLire "GCPDEPOT"."LECTURE" (CTX_LIGNE.GCPDEPOT_IDENT) VISUPIEC.DEPOT_CODE = I_GCPDEPOT.CODE Memsoft le 26.09.2013 PAGE 36/42

VISUPIEC.ENTETE_IDENT = vtemp Ecrire VISUPIEC FinSi FinSi FinTantQue // Reinitialisation des caches TailleCacheLecture(CTX_LIGNE) = 1 TailleCacheLecture(CTX_ENTETE) = 1 AppliquerMethodeComposant "GCPDEPOT"."BASCULERCONTEXTEDISQUE" FinMethode FinObjet Après cette optimisation nous aurons à peu près Un «select *» pour charger la table GCPDEPOT nblignes/1000 «select top 1000» sur les lignes nb_entêtes/1000 «select top 1000» sur les entêtes Exemple: pour 10 000 factures de 10 lignes dont 100 concernent le client nous aurons 1 + 100000/1000 + 10000/1000 = 111 requêtes Le second exemple passe par une re-ecriture de l algorithme qui n est pas très efficace à l origine : il utilisera les index pour filtrer le nombre d enregistements parcourru. Le temps de traitement est énormément réduit. Methode "DEBUT" Variables : Chaine vtemp AppliquerDefaut Supprimer VISUPIEC AppliquerMethodeComposant "GCPDEPOT"."BASCULERCONTEXTEMEMOIRE" TailleCacheLecture(CTX_ENTETE) = 1000 TailleCacheLecture(CTX_LIGNE) = 100 // le cache peut être plus petit car vidé pour chaque nouvel entête (mais quj peut le plus...) // on pose d'abord le filtre sur les clients DebutRequete CTX_ENTETE Filtre(CTX_ENTETE.GCPCLI_IDENT,EgalA,VIDCLI) PositionDebut FinRequete // on boucle sur les factures du client TantQue LireSuivant(CTX_ENTETE) // on selectionne les lignes associées dont le code article est non nul DebutRequete CTX_LIGNE Filtre(CTX_LIGNE.NUMERO,DebutePar,CTX_ENTETE.IDENT + " ") Filtre(CTX_LIGNE.GCPARTIC_CODE,DifferentDe,"") PositionDebut FinRequete TantQue LireSuivant(CTX_LIGNE) VISUPIEC.PU_NET = CTX_LIGNE.HT/CTX_LIGNE.QTE VISUPIEC.QTNT = CTX_LIGNE.QTE-CTX_LIGNE.QTT (...) VISUPIEC.CLIART_DESIG = CTX_LIGNE.DESIG AppliquerMethodeComposantLire "GCPDEPOT"."LECTURE" (CTX_LIGNE.GCPDEPOT_IDENT) VISUPIEC.DEPOT_CODE = I_GCPDEPOT.CODE Memsoft le 26.09.2013 PAGE 37/42

VISUPIEC.ENTETE_IDENT = CTX_ENTETE.IDENT Ecrire VISUPIEC FinTantQue FinTantQue // Reinitialisation des caches TailleCacheLecture(CTX_LIGNE) = 1 TailleCacheLecture(CTX_ENTETE) = 1 AppliquerMethodeComposant "GCPDEPOT"."BASCULERCONTEXTEDISQUE" FinMethode Après cette optimisation nous aurons à peu près Un «select *» pour charger la table GCPDEPOT quelques «select top 1000» sur les entêtes (nb factures pour le client / 1000) autant de «select top 100» sur les lignes qu il y a de factures Exemple: pour 10 000 factures de 10 lignes dont 100 concernent le client nous aurons 1 + 1 + 100 = 102 requêtes (les 100 requêtes surf les lignes ne retournant chacune que 10 enregistrements). 5.5 Optimisation de LST_SELECTION Les tris sur les colonnes des listes font appel à la methode LST_SELECTION de l objet afin de pouvoir lire les champs interfaces. Le tri s effectuant sur toute la table (contrairement à l affichage de la liste), la methode LST_SELECTION est appelée pour tous les enregistrements de la table. Les lectures d interfaces destinées aux champs en lien sont alors très pénalisantes. On va donc ajouter un paramètre indiquant que l appel à LST_SELECTION s effectue dans le cadre d un tri, et un paramètre indiquant le nom du champ courant sur lequel on trie. Ceci permettra de limiter les lectures d interface. Exemple : Methode LST_SELECTION Parametres : Entier r, v, b, ctx Chaine ctri // debut modif NID v6.10 inactif : dessin Si NO_MAIL=1 vetat="inactif.bmp" Sinon Memsoft le 26.09.2013 PAGE 38/42

vetat="" FinSi // fin modif NID v6.10 dessin inactif //Lecture de l'adresse par défaut Si ctri="" ou position("i_gcpadr", ctri) <> 0 Alors AppliquerMethodeComposantLire "GCPADR"."LECTURE"( GCPADRF_IDENT ) //Adresse de facturation FinSi //Lecture de la famille client Si ctri="" ou position("i_gcpfclt", ctri) <> 0 Alors AppliquerMethodeComposantLire "GCPFCLT"."LECTURE"( GCPFCLT_IDENT ) FinSi //Lecture du contact principal Si ctri="" ou position("i_gcpconta", ctri) <> 0 Alors AppliquerMethodeComposantLire "GCPCONTA"."LECTURE"( GCPCONTA_IDENT ) FinSi Memsoft le 26.09.2013 PAGE 39/42

Quelques Limites de cette version - Un répertoire oxypp doit être partagé sur le réseau, car il contient toujours le dictionnaire et un certain nombre de tables, comme la table PREF - Les documents partagés (GED / images attachées aux fiches) ne sont pas gérés dans la base SQL Server. - Les chaines sont toujours limitées à 256 caractères Que faire si Oxygène refuse de démarrer Message d erreur sur la table SYSDOS Vérifier que les droits ont été correctement définis sur toutes les bases SQL server Message d erreur sur la table DEV_DOS Supprimer la dll syspaseu.dll correspondant au traitement de la vérification de la cohérence des monnaies de stockage des dossiers (pas utile en version SQL Server) Oxygène ne démarre plus après conversion de la base système Lancer la relocalisation de la base système en ligne de commande Memsoft le 26.09.2013 PAGE 40/42

Annexe A : exemples //Utilisation des contextes mémoires pour modifier des données Objet TRAITEMENT:TESTER_CONTEXTE_MEMOIRE "Tester les contextes mémoire" Declaration TABLE : GCPLFAC TABLE_SECONDAIRE : -> GCPLFAC_2 TABLE_SECONDAIRE : "MEM:GCPLFAC"->"LES_LIGNES_MEMOIRE" Variables : FinDeclaration Methode "INIT" AppliquerDefaut CreerContexteMemoire(TABLE) FinMethode Methode "FAIRE" AppliquerMethode "TESTER" FinMethode Methode "TESTER" BasculerContexteDisque(TABLE) //charger LES_LIGNES_MEMOIRE Requete TABLE.NUMERO, DebutePar, "00000001" + " " PeupleContexteMemoire TABLE, "EXTRACTION_LIGNES" //modifier LES_LIGNES_MEMOIRE PositionDebut LES_LIGNES_MEMOIRE TantQue LireSuivant (LES_LIGNES_MEMOIRE) LES_LIGNES_MEMOIRE.QTT = LES_LIGNES_MEMOIRE.QTT + 1 FinTantQue Si DebuterTransaction <> 0 Alors AppliquerMethode "TRAITE_ERREUR" ("transaction impossible") FinSi //reporter les modifications LES_LIGNES_MEMOIRE // TABLE basculée en contexte mémoire LES_LIGNES_MEMOIRES BasculerContexteMemoire(TABLE) PositionDebut TABLE TantQue LireSuivant(TABLE) Alors Si Lire (GCPLFAC_2.IDENT,EgalA, TABLE.IDENT) Alors Annuler GCPLFAC_2 FinSi //Copiercontexte copie l enregistrement depuis le contexte en //cours (mémoire) vers l autre contexte (table) CopierContexte(TABLE) FinTantQue BasculerContexteDisque(TABLE) Si Debug = 1 Alors Afficher "LDEV_DSK", "LDEV_MEM" FinSi Si ValiderTransaction <> 0 Alors AppliquerMethode "TRAITE_ERREUR" ("Validation impossible") FinSi FinMethode Methode "EXTRACTION_LIGNES" FinMethode FinObjet Memsoft le 26.09.2013 PAGE 41/42

Memsoft le 26.09.2013 PAGE 42/42