Certains types de données ADELIA se comportent différemment selon le gestionnaire de bases de données utilisé.
Type alphanumérique
Oracle
Oracle considère une chaîne vide comme une valeur NULL. Pour ne pas créer de conflit avec la contrainte NOT NULL WITH DEFAULT, la valeur par défaut pour les champs de type caractère est un blanc (" ") et non pas une chaîne vide.
Les données caractères de longueur supérieure à 2000 caractères sont stockées dans des colonnes de type LONG (Oracle 8i ou <) ou CLOB (Oracle 9 ou >). Elles héritent alors des limitations de ce type de données ORACLE (voir le type image).
SQL Server
Les données caractères de longueur supérieure à 8000 caractères sont stockées dans des colonnes de type TEXT, ce qui peut entraîner des limitations sur l'utilisation de certaines fonctions SQL (voir le type image).
Type alphanumérique Unicode
Oracle
Les types Unicode sont stockés en tant que NCHAR/NVARCHAR. La base de données doit donc avoir été créée avec un jeux de caractères nationaux compatible UCS-2 (de préférence AL16UTF16).
DB2-UDB
L'utilisation du type Unicode nécessite DB2 8.1 au minimum, et la création d'une base de données de type Unicode. L'utilisation de DB2 9.5 est recommandée (résout certaines inconsistances dans les fonctions caractères).
Attention : Dans une base DB2 unicode, le type CHAR est considéré comme un octet mais stocké en UTF-8. Cela peut poser des problèmes avec les caractères non-ascii qui sont codés sur plusieurs octets : une chaîne contenant 5 caractères accentués (éèêàô) nécessite par exemple un CHAR(10) pour être stocké. De plus, avec une version antérieure à DB2 9.5, la fonction scalaire sql "longueur" renvoie un nombre d'octets (longueur ('éèêàô') = 10 dans une base UNICODE).
Type image
Le type image est implémenté différemment selon le SGBD utilisé.
Oracle
Version 9i ou >
Le type image est implémenté sur le type Oracle BLOB. Certaines limitations existent au niveau de la manipulation de ces données, mais elles sont peu contraignantes.
Version 8i ou <
La grammaire SQL est très limitée en ce qui concerne le type LONG RAW (implémentation du type Adélia image) : une seule colonne de ce type peut exister dans une table, et cette colonne ne peut être référencée que par une requête SELECT.
SQL Server et DB2
Certaines limitations existent au niveau de la manipulation de ces données, mais elles sont peu contraignantes.
Type date
SQL Server
Le type DATETIME a pour intervalle de valeurs 1/1/1753 - 31/12/9999. La valeur *LOVAL d'Adélia (premier janvier de l'an zéro) n'est pas reconnue. Il est donc impératif d'initialiser toutes les variables date de vos programmes.
Type timestamp
Oracle
Oracle ne propose pas de type TIMESTAMP. Les TIMESTAMP Adélia sont donc générés sur le type DATE, qui est limité en précision à la seconde.
SQL Server
SQL Server ne propose pas de type TIMESTAMP. Les TIMESTAMP Adélia sont donc générés sur le type DATETIME, qui est limité en précision à 3.33 millisecondes.
Type numérique auto-incrément
Une colonne de type auto-incrément est une colonne de type numérique entier dont la valeur est générée automatiquement par le gestionnaire de base de données. De façon générale, il ne faut pas spécifier cette colonne dans un INSERT ou un UPDATE. Ce type de colonne est utilisé pour générer une clé automatiquement.
Attention, la récupération de la valeur de l'auto-incrément après un INSERT (option *RECUP_VAL_GEN de CREER_SQL) n'est supportée que pour les SGBD gérés par Adélia via les pilotes natifs (C, JDBC ou AS/400). De même, le type auto-incrément n'est supporté qu'en génération SQL.
Oracle
Le type auto-incrément est émulé par un trigger et une séquence générés par la génération du MPD Adélia. Il est possible d'insérer explicitement des valeurs dans la colonne, mais la séquence n'est pas mise à jour automatiquement. Il est donc possible, dans ce cas, de provoquer des clés en double.
Le type auto-incrément n'est pas supporté dans la déclinaison Mobile d'Oracle (Oracle Lite).
DB2-UDB
Le type auto-incrément est supporté par le SGBD (GENERATED BY DEFAULT AS IDENTITY). Il est possible d'insérer explicitement des valeurs dans la colonne, mais la séquence n'est pas mise à jour automatiquement. Il est donc possible, dans ce cas, de provoquer des clés en double.
Le type auto-incrément est supporté dans la déclinaison Mobile de DB2 (DB2 Everyplace).
SQL Server
Le type auto-incrément est supporté par le SGBD (IDENTITY). Il n'est pas possible d'insérer explicitement des valeurs dans la colonne, sauf en activant le flag IDENTITY INSERT (SET IDENTITY INSERT <NomTable> ON) sur la table.
Dans ce cas, la séquence est mise à jour automatiquement.
Le type auto-incrément est supporté dans la déclinaison Mobile de SQL Server (SQL Server Compact Edition).
MySQL
Le type auto-incrément est supporté par le SGBD (AUTO_INCREMENT). Il est possible d'insérer explicitement des valeurs dans la colonne. Dans ce cas, la séquence est mise à jour automatiquement.
Attention, sur MySQL, la colonne auto-incrément doit être définie comme premier élément de la clé primaire de la table (Identifiant 1 et génération de la table avec clé).
Microsoft Access
Le type auto-incrément est supporté par le SGBD (AutoNumber ou COUNTER). Il est possible d'insérer explicitement des valeurs dans la colonne. Dans ce cas, la séquence est mise à jour automatiquement.
Attention, sur Access le type auto-incrément est obligatoirement un binaire sur 4 octets. Vous êtes donc limité en précision à l'exécution, à un numérique (9,0) indépendamment de la définition Adélia.
DB2/400
Le type auto-incrément (GENERATED BY DEFAULT AS IDENTITY) n'est supporté qu'à partir de la V5R2MO de l'OS/400.
PostgreSQL
Le type auto-incrément est supporté par le SGBD (GENERATED BY DEFAULT AS IDENTITY). Il est possible d'insérer explicitement des valeurs dans la colonne, mais la séquence n'est pas mise à jour automatiquement. Il est donc possible, dans ce cas, de provoquer des clés en double. ↑ Haut de page