Autres améliorations augmentant la facilité d’emploi

où l’utilisation d’une table de résultats temporaires entraîne l’ODP
SQL à  ne plus être réutilisable. Le moteur utilise toujours des tables de résultats
temporaires, mais elles ne génèrent plus des ODP non-réutilisables.

En V4R5, la taille maximale des récepteurs de journaux passe
de 2 Go à  1 To

Si on utilise la journalisation des fichiers sur l’AS/400 et que
l’on a des taux de transactions relativement élevés, la gestion de ces fichiers
est désormais plus simple avec des possibilités de journaux de taille conséquente.
En V4R5, la taille maximale passe de 2 Go à  1 To, réduisant la fréquence de
changement des récepteurs de journaux. Parallèlement, le nombre maximum du nombre
de séquences du journal passe de 2 à  10 milliards, ce qui réduit la fréquence
de réinitialisation des séquences de nombres.
Les tables DB2 UDB sont également de taille plus conséquente en V4R5. Le nombre
maximum de lignes autorisé dans une table passe de 2,1 à  4,2 milliards. La taille
maximale de la table reste d’un demi tera-octet. On peut en outre référencer
plus de tables (jusqu’à  256) sur une seule instruction SQL.
Les utilitaires Data Loader AS/400 (commandes CL CPYFRMIMPF et CPYTOIMPF) sont
plus faciles à  utiliser en V4R5. CPYFRMIMPF (Copy From Import File) a été améliorée
afin de supprimer les espaces superflus en début de chaîne et d’attribuer une
valeur par défaut aux colonnes (au lieu d’affecter une valeur nulle) lorsqu’une
colonne de la base de données cible n’autorise pas de valeurs nulles. CPYTOIMPF
(Copy To Import File) possède un nouveau paramètre permettant de préciser le
code de page du fichier stream cible. Ainsi, il n’est plus indispensable de
créer le fichier stream cible à  l’avance lorsqu’on a besoin d’un code de page
spécifique.

Un autre apport de laV4R5 pour DB2 UDB réside dans les procédures
cataloguées Java