Retour d'expérience migration 2016 - 2019

La migration 2016-->2019 touche à la structure des bases en modifiant les colonnes varchar en nvarchar pour le support des alphabets non latins (UTF8).

Cette opération est longue particulièrement sur des bases volumineuses , voici quelques conseils pour optimiser le temps de migration :

1. Purger le log de la base de données et passe en mode de récupération simple

2. Désactiver les triggers sur les tables Documents, DocumentProcessAccessRights, DocumentProcess, DocumentAccessRights

3. Supprimer temporairement les index spécifiques au projet (les index produits sont basés sur des primary keys) ces index sont généralement basés sur des varchar qui passe en nvarchar. Vous trouverez ci-après un script sql qui produit le sql CreateIndexScript.sql nécessaire à la recréation des index.

4. **Point de vigilance : si vous avez des index avec colonnes incluses et que ces colonnes passent en nvarchar vous pouvez avoir un dépassement de capacité d'index à sa recréation. Il est alors nécessaire de reprendre les champs dans les formulaires pour réduire leur taille et/ou de revoir cet index Exemple de message d'erreur: La longueur de clé maximale est 900 octets. L'index 'MK1_Facture' a une longueur maximale de 1036 octets. Dans certains cas, la combinaison de valeurs élevées entraînera l'échec de l'opération d'insertion/mise à jour.