© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Deux nouveaux types de projets de données font leur apparition dans le plan de travail :
- Projets de conception de données
- Projets de développement de données
Les projets de conception servent à créer et à stocker des modèles de données ; par exemple, des modèles de données physiques et des modèles de données logiques. Les projets de développement servent pour leur part à créer et à stocker des objets de développement d'applications de données, tels que des procédures mémorisées et des fonctions utilisateur (que l'on appelle également routines). Les routines sont également visibles dans le cadre d'un modèle de données physiques à partir d'un projet de conception de données. Cependant, le support de développement de routines à partir d'un projet de conception est très limité. En particulier, il ne prévoit pas d'outils de développement SQL. Si vous devez développer des routines, utilisez de préférence le projet de développement de données prévu à cet effet, car avec ses assistants, ses éditeurs de routines, ses fonctions de débogage et l'intégration d'outils SQL, il offre un support de développement beaucoup plus complet.
Dans l'éditeur de données de table, si vous effectuez une validation XML sur une table XML dépourvue de clé primaire, cette validation ne fonctionne que la première fois, c'est-à-dire lorsque vous insérez la valeur XML. En outre, si vous mettez à jour une colonne XML existante soumise à une validation XML, cette mise à jour échouera.
Solution : Créez systématiquement une clé primaire dans les tables qui contiennent des colonnes XML.
Travailler avec plusieurs éléments racine dans cet éditeur peut conduire à des erreurs lorsque vous enregistrez le fichier XSD annoté.
Solution : Créez un jeu de fichiers de définition XML Schema séparé pour chaque élément racine.
Pour pouvoir utiliser des types de données XML et travailler sur des schémas XML, vous devez être connecté à une base de données UTF-8. Il n'existe pas de limite à la quantité de données renvoyée par la base de données pour les documents XML. Si la quantité de données renvoyée est particulièrement grande, les performances peuvent être affectées.
- Dans sa version actuelle, l'éditeur SQL d'admet pas les variables hôte durant l'exécution de l'action Exécuter SQL.
Solution : Vous pouvez exécuter le code SQL à partir du générateur SQL, s'il s'agit d'une instruction DML (langage de manipulation de données).
- Le générateur SQL ne prend pas en charge l'intégralité de la syntaxe SQL. Par exemple, les types définis par l'utilisateur (UDT) et les fonctions de table ne sont pas reconnus.
- Les types définis par l'utilisateur (UDT) ne sont pas admis comme paramètres passés aux routines.
- Pour déployer des procédures mémorisées Java™ destinées à DB2 Universal Database™ for iSeries® à partir du système de fichiers en utilisant l'outil de déploiement Ant, vous devez veiller à ce que le fichier jt400.jar se trouve dans votre chemin de classes système. Si vous tentez de déployer une procédure mémorisée exportée en suivant les instructions du fichier DeployInstructions.txt, vous risquez de recevoir le message d'erreur :
...[createsp] Impossible de se connecter à la base de données cible.
[createsp] com.ibm.db2.jcc.DB2Driver...Solution : Vérifiez que db2jcc.jar et les fichiers de licences appropriés se trouvent dans votre chemin de classes système.
- Lorsque vous déployez ou exécutez des procédures mémorisées Java, il est possible que vous receviez un message d'erreur signalant l'impossibilité de charger une classe. Cela peut arriver si RAD v7 et le serveur DB2® n'utilisent pas la même version de JDK et si, notamment, le serveur DB2 utilise une version plus ancienne.
Solution : Vous devez spécifier l'option "-source 1.4" dans le champ Options de compilation de l'assistant de déploiement de routines lorsque vous déployez des procédures Java sur un serveur utilisant un JDK niveau 1.4 (c'est le cas, notamment, d'un serveur DB2 Universal Database pour Linux®, UNIX® et Windows® V8.2). D'une manière générale, utilisez l'option de compilation appropriée "-source niveau de JDK " afin que les routines soient compilées en fonction du niveau de JDK du serveur de base de données cible.
- Lorsque vous déployez une procédure mémorisée ou une fonction utilisateur à l'aide de la fonction de déploiement Ant, il est possible que vous receviez le message suivant si le fichier tools.jar ne se trouve pas sur votre chemin de classes :
Unable to locate tools.jar. Expected to find it in F:\jre\1.4.2\lib\tools.jar
Le fichier tools.jar fait partie de l'environnement d'exécution Java (JRE) et non de l'outil de déploiement Ant.Solution : tools.jar n'est pas nécessaire à l'exécution du script Ant. Vous pouvez donc ignorer ce message.
- Lorsque vous changez le nom d'une méthode Java dans l'éditeur de procédure mémorisée, vous ne pouvez pas ensuite enregistrer correctement la procédure en cliquant avec le bouton droit sur la page Source de l'éditeur et en choisissant Enregistrer.
Solution : Enregistrez la procédure mémorisée en sélectionnant Fichier->Enregistrer sur la barre de menus, en appuyant sur Ctrl+S ou en cliquant sur l'icône Enregistrer de la barre d'outils.
- Si vous faites glisser une procédure mémorisée ou une fonction utilisateur entre deux serveurs de nature différente (par exemple, d'un serveur DB2 Universal Database pour Linux, UNIX et Windows vers un serveur DB2 Universal Database pour z/OS®), un message vous avertit, pendant l'opération de glisser-déposer, de certaines incompatibilités entre les deux serveurs. Si vous poursuivez l'opération et tentez ensuite d'ouvrir la procédure mémorisée ou la fonction utilisateur, il est possible que vous receviez un message d'erreur.
- Le profilage de procédures SQL sur un serveur DB2 UDB pour Linux, UNIX et Windows V8.2 peut provoquer le lancement d'une exception de pointeur null (NullPointerException) s'il manque sur ce serveur la procédure prérequise SYSIBM.SQLCAMESSAGECCSID. Celle-ci est en effet utilisée par le pilote JCC pour obtenir le texte des messages d'erreur.
Solution : Vous pouvez créer une connexion au serveur sans le réglage retrieveMessagesFromServerOnGetMessage=true.
- Durant la surveillance de l'exécution d'une procédure SQL, des événements sont générés pour les instructions DML telles que INSERT, SELECT, DELETE et UPDATE qui sont émises dans la procédure. En revanche, aucun événement n'est généré de manière déterministe pour les instructions procédurales telles que les affectations de variables et les structures de contrôle telles que WHILE ou IF. Par conséquent, il est possible qu'aucune information de profilage ne soit générée pour les instructions procédurales.
- Lorsque vous êtes connecté à un serveur DB2 fonctionnant sous UNIX, des exceptions pour dépassement de délai (timeout) peuvent se produire quand vous ajoutez des points d'arrêt ou que vous exécutez une procédure en mode débogage.
- Le débogueur ne fonctionne pas pour une procédure dont le nom contient à la fois des caractères de l'alphabet latin et des caractères chinois.
- Les expressions de contrôle sont admises uniquement pour les procédures mémorisées Java dynamiques. Elles ne le sont pas pour les procédures SQL et SQLJ.
- Le débogueur ne s'arrête pas à un point d'arrêt si celui-ci n'est pas placé sur la première unité syntaxique (par exemple, SET) d'une instruction exécutable. En outre, il ne s'arrête pas sur DECLARE CONTINUE, CLOSE CURSOR ou ROLLBACK.
- Si vous déboguez une procédure mémorisée Java et que vous sélectionnez une action Terminer, la session de débogage peut mettre plusieurs minutes à s'arrêter complètement. Les nouvelles sessions de débogage démarrées pendant cette période peuvent se révéler instables.
- Si vous déboguez une procédure mémorisée Java qui en appelle une autre, vous ne pouvez pas déboguer cette seconde procédure. Il n'est pas possible d'entrer en mode pas à pas dans la procédure imbriquée et les éventuels points d'arrêt qu'elle contient sont ignorés. Cette restriction s'applique à Linux, UNIX et Windows.
- Si vous recevez un message d'erreur 'Le délai est arrivé à expiration lors de l'attente du paquet' pendant le débogage d'une procédure mémorisée Java, essayez d'augmenter le délai d'expiration du débogueur Java.
Solution : Pour augmenter le délai d'expiration du débogueur Java, sélectionnez Fenêtre > Préférences sur la barre de menus du plan de travail. Développez la branche Java et cliquez sur Débogage. Sur la page de préférences Débogage, augmentez la valeur du champ Délai d'expiration du débogueur (ms) dans la section Communication. Il est conseillé de spécifier une valeur au moins deux fois plus élevée que la valeur par défaut.
- Lorsque vous déboguez une procédure mémorisée Java, si vous utilisez l'action Modifier la valeur pour modifier une variable dont la valeur est une chaîne vide, il est possible que le bouton OK de la fenêtre d'édition ne soit pas disponible.
Solution : Pour activer ce bouton, sélectionnez l'option Entrez une évaluation, spécifiez une chaîne non vide comme valeur (par exemple, 'a'), puis sélectionnez l'option Entrez un texte littéral. Le bouton OK deviendra alors disponible.
- Si vous ne voyez pas les variables locales lorsque vous déboguez une procédure mémorisée Java, il est possible que celle-ci ait été déployée sans l'option de compilation -g.
Solution : Veillez à spécifier cette option de compilation lorsque vous déployez des procédures mémorisées Java.
- Si vous voyez un message 'Cadre de pile non valide' dans la vue Variables, passez dans la vue Débogage et cliquez sur l'objet thread (unité d'exécution) au-dessus du cadre de pile, puis cliquez sur le cadre de pile lui-même. Cela doit normalement actualiser la vue Variables et faire disparaître le message d'erreur.
- Lorsque vous déboguez une procédure mémorisée SQLJ exécutée sur DB2 UDB pour iSeries V5R4, la ligne en cours d'exécution ne correspond pas à la ligne source SQLJ affichée dans la vue Débogage, sauf si vous avez appliqué un PTF (correctif) iSeries qui met à jour la mappe de lignes (linemap) afin de la faire correspondre à la source SQLJ au lieu de la source Java.
- La valeur du paramètre 'Délai d'expiration du gestionnaire de session en minutes' n'est pas reconnue dans les préférences du débogueur (ce paramètre est accessible lorsque vous sélectionnez Fenêtre > Préférences, puis que vous développez la branche Exécution/Débogage et cliquez sur DB2 Stored Procedure Debugger.
- Le débogueur ne peut pas prendre en charge une procédure mémorisée exécutée sur DB2 pour Linux, UNIX et Windows et comportant un trop grand nombre de variables. Le nombre de variables est limité à 200.
- Mouvement du curseur dans une session de débogage : dans certains cas, lorsqu'il y a plusieurs déclarations de variables dans une procédure, vous devez cliquer plusieurs fois sur Avancer d'un pas avec entrée ou Avancer d'un pas sans entrée pour pouvoir passer à la ligne suivante. Par exemple, vous devez cliquer deux fois sur cette ligne : DECLARE v_dept, v_actdept CHAR(3); et trois fois sur celle-ci : DECLARE v_bonus, v_deptbonus, v_newbonus DECIMAL(9,2); Vous devez cliquer un nombre de fois égal au nombre de déclarations de variables.
- Si vous démarrez une session de débogage pour une procédure mémorisée Java et que vous ajoutez des points d'arrêt, puis que vous les désactivez, ils demeurent activés.
Solution : Lorsque vous démarrez une nouvelle session de débogage, supprimez d'abord tous les anciens points d'arrêt, puis ajoutez-en de nouveaux.
- Dans certains cas, lorsque vous travaillez sur plusieurs projets de développement de données et que vous tentez de déboguer une procédure mémorisée, il est possible que vous receviez le message "Impossible de localiser la procédure mémorisée NOM_PROCEDURE. Elle a peut-être été supprimée de l'espace de travail." ou "Source introuvable".
- Après le débogage d'une procédure SQL imbriquée, il arrive que le débogueur reste actif, comme en témoigne la vue Sortie de données. Cela peut perturber les exécutions ou déploiements subséquents de procédures mémorisées.
Solution : Le gestionnaire de session doit être exécuté sur la machine client où le produit de développement est installé. Pour démarrer le gestionnaire de session, exécutez le fichier db2dbgm.bat à partir du sous-répertoire bin du répertoire d'installation du produit.
- Le support de débogage des procédures mémorisées est limité sur les serveurs DB2 V8 pour Linux, Unix, Windows et z/OS. Seules les procédures SQL peuvent être déboguées sur un serveur DB2 V8 et celui-ci doit être complété du fixpack 14. En outre, le gestionnaire de session doit être exécuté sur la machine client où le produit de développement est installé. Pour démarrer le gestionnaire de session, exécutez le fichier db2dbgm.bat à partir du sous-répertoire bin du répertoire d'installation du produit.
- ALIAS, MQT, NICKNAME et SYNONYM sont maintenant pris en charge durant l'ingénierie aller-retour, mais pas dans le processus de mappage d'EJB.
- Support limité de MySQL 4.1 : les propriétés suivantes ne sont pas affichées correctement dans la vue Propriétés : index unique, colonnes à incrémentation automatique et valeur par défaut pour les colonnes NULL et binaire. En outre, les procédures et fonctions C ne sont pas supportées.
- Les déclencheurs, les contraintes de vérification et les vues ne sont pas pris en charge pour Cloudscape® v5.1 : les déclencheurs et contraintes de vérification Cloudscape v5.1 ne sont pas affichés dans l'explorateur de base de données. Les vues Cloudscape v5.1 sont absentes du corps SQL dans la vue Propriétés. Vous ne pouvez pas générer de fichier DDL ni appliquer l'ingénierie inverse aux déclencheurs, contraintes de vérification et vues Cloudscape v5.1.
- Le support des types de données structurées définis par l'utilisateur dans Oracle est limité : le nom d'un tel type n'est pas inclus dans la définition de table lorsque vous générez le fichier DDL d'une table Oracle.
- Lorsque vous fermez l'éditeur de comparaison après avoir comparé des objets dans la vue Explorateur de base de données, si vous actualisez (ou régénérez) ensuite un objet conteneur dans cette vue, l'opération peut échouer et provoquer l'exception "Impossible de modifier l'ensemble de ressources sans une transaction d'écriture". Par exemple, la comparaison d'une table de votre modèle de données physiques à la source originale de cette table peut provoquer cette exception.
Solution : Lorsque cela arrive, vous pouvez sélectionner le conteneur de l'objet conteneur et tenter une nouvelle actualisation. Par exemple, si l'actualisation d'une table échoue, essayez d'actualiser le schéma qui la contient. Si cette nouvelle tentative échoue elle aussi, déconnectez-vous de la base de données et reconnectez-vous.
Si vous définissez une table avec une seule colonne de type XML (ou une table avec des lignes non uniques) et que vous utilisez ensuite l'éditeur de table pour supprimer une ligne, toutes les lignes identiques à cette ligne sélectionnée sont également supprimées.
Solution : N'utilisez pas l'éditeur de données de table pour supprimer une ligne dans une table qui contient des lignes identiques.