Limitations et considérations générales
Dernière mise à jour : 20/10/2026Vous devez connaître les limitations et les considérations générales suivantes lorsque vous utilisez une source Microsoft SQL Server (Microsoft CDC based) :
Limitations et considérations générales concernant l'ensemble des tâches de données
- Un service Microsoft Azure SQL Managed Instance secondaire n'est pas supporté comme base de données source.
- Les données Déplacement provenant de vues indexées ne sont pas supportées.
- Lors de la réplication d'un sous-ensemble de colonnes, Data Movement gateway utilise le paramètre @captured_column_list pour activer CDC uniquement sur les colonnes incluses. Vous pouvez définir le paramètre manuellement avant de démarrer la tâche. Les noms de colonne répertoriés avec le paramètre ne peuvent pas dépasser 127 caractères.
- Les limitations liées à l'obligation d'avoir activé MS-CDC sur toutes les tables sources comprennent :
- La troncation de table n'est pas supportée.
- Les utilitaires WRITETEXT et UPDATETEXT ne sont pas supportés.
Pour en savoir plus sur les limitations de MS-CDC, voir l'aide Microsoft.
-
Dans le cas d'une exécution sans le rôle db_owner, les limitations suivantes s'appliquent :
-
La capture des DDL n'est pas supportée. Pour éviter les erreurs de déplacement, vous devez décocher la case Capturer les événements liés à un DDL dans les paramètres de connexion avant d'exécuter la tâche.
-
MS-CDC ne peut pas être activé automatiquement et doit donc être activé manuellement. Pour éviter les erreurs de déplacement, vous devez décocher la case Activer MS-CDC sur toutes les tables capturées dans les paramètres de connexion avant d'exécuter la tâche.
Note InformationsDes autorisations particulières sont nécessaires pour une exécution sans le rôle db_owner. Pour plus d'informations, consultez Autorisations requises. -
- Déplacement de colonnes calculées est pris en charge uniquement dans les tâches de déplacement pour chargement complet. Pendant le traitement CDC, les opérations INSERT des colonnes calculées apparaissent comme NULL dans la cible et les opérations UPDATE sont ignorées.
- La commutation de partitions n'est pas supportée.
-
Le modèle DML suivant n'est pas supporté :
select <*> into <new_table> from <existing_table>
- Le chiffrement au niveau des colonnes n'est pas supporté. Ces tables seront écrites dans la cible sans les colonnes chiffrées.
- L'instruction ADD COLUMN DDL n'est pas supportée. Lorsqu'une instruction ADD COLUMN DDL est exécutée, la table est répliquée dans la cible sans la ou les colonnes récemment ajoutées et un avertissement est affiché.
- Lors de l'insertion d'une valeur dans les types de données spatiales de Microsoft Azure SQL Server Managed Instance (GEOGRAPHY et GEOMETRY), on peut soit ignorer la propriété SRID (Spatial Reference System Identifier), auquel cas le SRID par défaut est utilisé (0 pour GEOMETRY et 4326 pour GEOGRAPHY), soit spécifier un numéro différent. Lors de la déplacement de tables avec des types de données spatiales, Data Movement gateway remplace le SRID qui a été inséré par l'utilisateur par le SRID par défaut.
- Les index de type Columnstore ne sont pas supportés.
- Les tables optimisées pour la mémoire (utilisant In-Memory OLTP) ne sont pas supportées.
- Les bases de données temporelles ne sont pas supportées.
- La durabilité retardée n'est pas supportée.
- Une limitation ODBC ne permet pas d'intégrer plus de 16 colonnes à une clé primaire.
- Les données masquées sont créées dans la cible sans masque.
-
OpenLDAP n'est pas supporté.
-
Déplacement à partir des bases de données pour utiliser l'ADR (Accelerated Database Recovery, récupération de base de données accélérée) n'est pas pris en charge.
-
Déplacement une table ou un schéma qui contient une apostrophe (') dans son nom n'est pas pris en charge.
-
Les modifications appliquées à la base de données utilisant DACPAC ne sont pas capturées.
-
Les tables de modification MS-CDC avec des colonnes à taille fixe (incluant les données NCHAR et CHAR), dont la somme dépasse 8060 octets, ne sont pas supportées.
-
Les vues et les tables système ne sont pas supportées.
Limitations et considérations générales concernant les tâches de réplication et de dépôt temporaire
- En raison de l'obligation d'avoir MS-CDC activé sur l'ensemble des tables sources, les colonnes renommées ne seront pas capturées lors de l'exécution de CDC.
Pour en savoir plus sur les limitations de MS-CDC, voir l'aide Microsoft.
-
Les limitations liées à la capture des opérations DDL sont les suivantes :
- L'opération RENAME TABLE n'est pas capturée. Lorsque qu'un RENAME TABLE DDL est détecté, la tâche continue de capturer les modifications dans renommer la table cible. Si la tâche s'interrompt, puis reprend, ou s'il se produit une erreur récupérable, la table est suspendue pour permettre l'alignement manuel de la table CT.
- L'instruction ADD COLUMN DDL n'est pas supportée. Lorsqu'une instruction ADD COLUMN DDL est exécutée, la table est répliquée dans la cible sans la ou les colonnes récemment ajoutées et un avertissement est affiché.
-
Lors de l'exécution sans le rôle the db_owner, la capture des DDL n'est pas supportée.
Note InformationsDes autorisations particulières sont nécessaires pour une exécution sans le rôle db_owner. Pour plus d'informations, consultez Exécution sans le rôle db_owner. -
Lors d'une exécution sans le rôle db_owner, MS-CDC ne peut pas être activé automatiquement et doit donc être activé manuellement. Pour éviter les erreurs déplacement, vous devez également décocher la case Activer MS-CDC sur toutes les tables capturées dans les propriétés de la connexion avant d'exécuter la tâche.
-
La captures des instructions DDL et DML dans une seule transaction n'est pas prise en charge.
Fonctionnalités de sécurité non supportées
Les tables qui utilisent les fonctionnalités de sécurité suivantes ne sont pas supportées :
- Toujours chiffré
- Sécurité au niveau de la ligne
Types de données non supportés
Les types de données suivants ne sont pas pris en charge :
- CURSOR
- SQL_VARIANT
- TABLE
Les types de données définis par l'utilisateur sont pris en charge en fonction de leur type de base. Par exemple, les types de données définis par l'utilisateur en fonction de DATETIME sont traités comme un type de données DATETIME.