Accéder au contenu principal Passer au contenu complémentaire

Mise à niveau et désinstallation de Data Movement gateway

Cette rubrique explique comment mettre à niveau ou désinstaller votre installation Data Movement gateway. Elle contient également un tableau répertoriant les modifications lancées dans chaque version de Data Movement gateway.

Procédure de mise à niveau

Pour connaître votre version actuelle, accédez à Administration  > Passerelles de données et consultez la colonne Version correspondant à votre Data Movement gateway.

S'il existe une nouvelle version disponible, le numéro de version est suivi d'un !. Pour plus d'informations, survolez l'icône à l'aide de la souris.

Note InformationsLes versions sont parfois publiées sous forme de correctifs. Le ! ne sera affiché que si une nouvelle version standard est disponible (par opposition à une version corrective). Pour savoir si une version est un correctif ou une version standard, consultez la colonne Type du tableau Historique des versions Data Movement gateway ci-dessous.

Si la version de passerelle installée n'est pas supportée, l'État est Désactivé et une mise à niveau est nécessaire pour activer la passerelle.

Chaque fois qu'une nouvelle version du RPM Data Movement gateway est disponible, vous devez la télécharger depuis Administration et mettre à niveau l'installation existante.

Pour effectuer cette action :

  1. Téléchargez la nouvelle version en cliquant sur sur la passerelle, puis sur Mettre à niveau.

    Acceptez le contrat client et téléchargez le RPM.

  2. Ouvrez une invite shell et remplacez le répertoire de travail par le répertoire contenant le fichier RPM.
  3. Exécutez la commande suivante :

    Syntaxe :

    rpm -U <rpm name>

    Exemple :

    sudo rpm -U qlik-data-gateway-data-movement.rpm

  4. Démarrez le service Data Movement gateway :

    sudo systemctl start repagent

  5. Confirmez éventuellement le lancement du service :

    sudo systemctl status repagent

    Le statut doit être comme suit :

    Active: active (running) since <timestamp> ago

Data Movement gatewayHistorique des versions de

Version

Type

Date de publication

Modifications significatives

Date de fin du support

2024.5.35

Correctif

10 décembre 2024

Ce correctif résout les problèmes suivants :

  • Lors d'une tâche de stockage, le type de données NVARCHAR(3500) était incorrectement converti en VARCHAR(10500) au lieu de VARCHAR(8000) (le maximum autorisé), ce qui entraînait une erreur.

  • Lorsque la table source contenait un type de données GRAPHIC avec la page de code 941 (japonais), l'erreur suivante se produisait (extrait) :

    Unexpected CCSID '941' in column 'PNTNM'

Déterminé lors de la publication de la version majeure suivante.

2024.5.32

Correctif

26 novembre 2024

Après la mise à jour du nom d'utilisateur et du mot de passe dans le connecteur source Workday Reports, puis l'actualisation de la tâche, il se produisait une erreur « Nom d'utilisateur ou mot de passe non valide », même si les informations d'identification étaient correctes. Ce problème est désormais résolu.

Déterminé lors de la publication de la version majeure suivante.
2024.5.31

Correctif

19 novembre 2024

Ce correctif résout les problèmes suivants :

Oracle Java Standard Edition 17.0.8, livré avec Data Movement gateway, présente plusieurs vulnérabilités connues. Ce correctif remplace la version 17.0.8 par la version 17.0.12, ce qui résout les problèmes.

Lors d'une opération CDC, pour chaque modifications, plusieurs opérations INSERT étaient ajoutées à la table _ct associée (au lieu d'une seule). Cela augmentait considérablement le nombre d'enregistrements dans la table _ct.

Déterminé lors de la publication de la version majeure suivante.
2024.5.28

Standard

12 novembre 2024 Fournit les fonctionnalités nécessaires à la mise en place prochaine de la fonction Évolution du schéma. Déterminé lors de la publication de la version majeure suivante.
2024.5.27

Correctif

5 novembre 2024

Ce correctif résout les problèmes suivants :

Le 14 août 2024, Snowflake a publié un avis de sécurité concernant les pilotes JDBC Snowflake >= 3.2.6 et <= 3.19.1, dont certains étaient utilisés avec des versions antérieures de Data Movement gateway. La vulnérabilité a été corrigée dans le pilote JDBC Snowflake 3.20, qui est la version désormais installée avec l'utilitaire d'installation du pilote. Les clients existants doivent mettre leur pilote à niveau dès que possible en suivant la procédure Mise à jour du pilote décrite à la section Configuration du pilote.

  • Lors de l'utilisation de redo event 11.22, il manquait des opérations INSERT lors du traitement de plusieurs opérations INSERT sur une page compressée qui ne l'était pas avant les opérations INSERT.
  • Dans de rares cas, l'analyse incorrecte des événements DELETE dans l'enregistrement redo log générait un avertissement « L'événement Redo Log DELETE contient une structure inconnue », suivi de divers problèmes.

Les instructions du fichier YAML ont été mises à jour de sorte à refléter la version correcte du SAP Java Connector.

Lorsque vous utilisiez Data Movement gateway pour vous connecter à la cible Snowflake via un proxy, la connexion échouait en affichant l'erreur suivante :

500 Failed to connect to Data Movement Gateway

Déterminé lors de la publication de la version majeure suivante.
2024.5.22

Correctif

15 octobre 2024 Ce correctif résout un problème dans une tâche de réplication Chargement complet + CDC, dans laquelle le champ La tâche de données est à jour au de la tâche CDC affichait l'horodatage Chargement complet au lieu de l'horodatage ou des horodatages  CDC. Déterminé lors de la publication de la version majeure suivante.
2024.5.16

Correctif

8 octobre 2024
    • Il manquait parfois des opérations INSERT en présence de plusieurs opérations INSERT lors de l'utilisation de l'événement redo 11.22.
    • Après la mise à niveau d'Oracle 19g à l'aide du correctif July 2024, les opérations UPDATE n'étaient parfois pas capturées et l'avertissement suivant s'affichait :

      A compressed row cannot be parsed

  • Lorsque les paramètres de la tâche étaient configurés de sorte à créer le schéma de la table de contrôle, la tâche échouait avec l'erreur suivante :

    Failed to delete directory

  • Lorsqu'une tâche était planifiée pour s'exécuter périodiquement, elle échouait parfois avec l'erreur suivante :

    The task stopped abnormally

  • Les tâches de transformation et de stockage restaient parfois trop longtemps en file d'attente.

  • Les tâches échouaient en cas d'utilisation de l'indicateur de caractéristique use_manipulation_pk_for_apply avec la réplication Stocker les modifications.

  • Le délai d'expiration S3 a été étendu à 6 heures pour éviter les problèmes résultant de délais d'expiration prolongés tels que la perte du jeton pour télécharger les fichiers.

Déterminé lors de la publication de la version majeure suivante.
2024.5.14

Standard

10 septembre 2024
  • Clé/paire fournit une méthode d'authentification plus robuste que utilisateur/mot de passe pour vous connecter à Snowflake via vos comptes de service. Cette approche est recommandée pour les charges de travail telles que le chargement de données (tâches de réplication ou de dépôt temporaire) et les transformations.

  • Dans les versions précédentes, l'actualisation des métadonnées sur un jeu de données existant ou un jeu de données récemment ajouté échouait parfois avec une erreur. Cette amélioration garantit l'extraction sans aucun problème des métadonnées de plusieurs tables en parallèle.

  • Lorsqu'une table source contenait une colonne avec un type de données DECIMAL (par exemple, DECIMAL (38, 20)), la préparation de la tâche de stockage dans Google BigQuery échouait avec l'erreur suivante (extrait) :

    Column <n> in <table name> has incompatible types: STRING, BIGNUMERIC at [93:1]

    Le problème a été résolu en mappant le type de données DECIMAL source vers DECIMAL dans Google BigQuery.

  • Si des modifications étaient apportées à une règle de schéma existante dans une tâche de données, l'erreur suivante apparaissait :

    QRI SQL error not implemented

  • Lors de la préparation d'une tâche de dépôt temporaire qui se connectait à une source d'applications SAP, la tâche s'effectuait correctement, mais l'erreur suivante était signalée dans le fichier journal repsrv.log :

    Invalid object name 'hk1./QTQVC/QRI'

Déterminé lors de la publication de la version majeure suivante.
2024.5.7

Standard

6 août 2024
  • Auparavant, en cas de modification des métadonnées, toutes les tables étaient abandonnées et recréées, même si les modifications des métadonnées n'affectaient pas toutes les tables. Désormais, seules les tables modifiées seront abandonnées et recréées, ce qui améliore les performances.

  • Les tables créées dans la base de données source lors de la tâche de données de réplication qui correspondent au modèle d'inclusion seront désormais automatiquement capturées lors de l'opération CDC (Change Data Capture).

    • Auparavant, lors de la lecture de différentes transactions depuis Microsoft SQL Server (MS-CDC), Qlik Talend Data Integration préservait l'ID de transaction et l'horodatage de la première transaction uniquement. Sur la cible, cela donnait l'impression que les enregistrements faisaient partie d'une seule transaction. Désormais, Qlik Talend Data Integration préservera l'ID de transaction et l'horodotage d'origine de chaque enregistrement individuel. Cela constitue un avantage pour les clients qui souhaitent tirer parti des colonnes d'en-tête d'ID de transaction et d'horodatage dans les tables de modifications.

    • Auparavant, les octets de l'ID de transaction étaient chiffrés dans l'ordre inverse. À partir de cette version, les octets seront chiffrés dans le bon ordre. Information : les clients qui préfèrent conserver le comportement existant peuvent le faire via les paramètres internes. Pour des informations détaillées, contactez Qlik Support.

  • Qlik Talend Data Integration supporte désormais la mise en cache de l'authentification enfichable SHA-2 (caching_sha2_password) lors de l'utilisation de sources ou de cibles MySQL, localement ou dans le cloud. Dans les versions précédentes, seule l'authentification enfichable native (mysql_native_password) était supportée.

  • Les types de données BYTES et BLOB seront désormais mappés vers VARBYTE sur Amazon Redshift au lieu de VARCHAR.

    • PostgreSQL 16.x

    • MySQL 8.1
    • IBM DB2 pour z/OS 3.1
    • PostgreSQL 16.x
    • MySQL 8.1
    • Databricks 14.3 LTS
    • SQL Server ODBC Driver 18.3

Fin du support des versions de bases de données suivantes :

  • L'ensemble des versions et pilotes Oracle antérieurs à Oracle 19.x
  • Microsoft SQL Server 2014
  • MySQL 5.7
  • PostgreSQL 11
  • IBM DB2 pour LUW 10.5
  • IBM DB2 pour z/OS: z/OS 2.3
  • Lorsque la modification d'un document de groupe capturée supprimait toutes les lignes de toutes ses tables capturées, cela entraînait des messages d'opération DELETE manquante et d'assertion inutiles.

  • Mise à jour de Microsoft Authentication Library pour Java (MSAL4J) et Bouncy Castle vers des versions sans vulnérabilités connues.

    • La tâche échouait parfois avec le stockage interne Snowflake.
    • La tâche échouait lorsque le nom de schéma cible était en japonais Katakana.
  • Lors de la reprise d'une tâche avec une source Oracle, la tâche continuait à attendre la suppression d'un Archived Redo Log au lieu d'échouer avec une erreur appropriée.

Déterminé lors de la publication de la version majeure suivante.
2023.11.23

Standard

26 juin 2024
  • À partir de cette version, le schéma de métadonnées Snowflake (des fichiers intermédiaires) sera créé, s'il n'existe pas.

  • Après la modification d'une règle Renommer l'ensemble de données (qui concaténait le nom de table et le nom de schéma) et l'ajout d'une Vue à la tâche de dépôt temporaire, l'opération Préparer échouait avec l'erreur suivante :

    QRI SQL error not implemented.

  • Mise à jour du composant java_file_factory à une version exempte de toute vulnérabilité connue.
  • Mise à jour de org.postgresql:postgresql à une version exempte de toute vulnérabilité connue.
  • Lors du déplacement de données vers SQL Server, l'opération Préparer échouait lorsque les noms d'index dépassaient 128 caractères. Le problème a été résolu via l'altération de la logique pour créer des noms d'index plus courts.
  • Lors du déplacement de données depuis SQL Server, un nom de colonne manquant dans les définitions de table produisait une boucle de notification infinie dans le fichier repsrv.log avec le message suivant :

    mssql_resolve_sqlserver_table_column_attributes(...) failed to find column

6 février 2025

2023.11.11

Standard

21 mai 2024
  • Prise en charge supplémentaire permettant la récupération simultanée des métadonnées de plusieurs tables.

  • Les informations de surveillance des tâches de dépôt temporaire et de réplication seront désormais mises à jour toutes les 10 secondes (et non toutes les 60 secondes), fournissant ainsi une indication plus précise de leur statut actuel.

  • Le Japon est désormais pris en charge comme région de client Qlik Cloud.

  • L'intervalle de nouvelle tentative de la passerelle de données et de Qlik Cloud augmentait continuellement, mais ne se réinitialisait jamais (sauf si le service était redémarré).
  • Lors du déplacement de données d'une source d'applications SaaS, les tables passaient parfois à l'état d'erreur lors de l'actualisation.
  • Il arrivait que des tâches avec une source MySQL échouent avec l'erreur suivante lors de l'opération CDC :

    Read next binary log event failed; mariadb_rpl_fetch error 0 Error reading binary log.

  • Auparavant, les événements d'audit CDC étaient consignés uniquement pour les tâches de dépôt temporaire. Désormais, ils seront consignés également pour les tâches de réplication.
  • Lors du déplacement de données depuis SQL Server (MS-CDC), les tâches contenant un grand nombre de tables mettaient parfois plusieurs heures à démarrer.
  • Lorsque la table source contenait des colonnes de CLOB et que la valeur Limiter la taille de LOB dépassait 10 240, la réplication dans Snowflake échouait avec l'erreur suivante :

    Invalid character length: 0

Déterminé lors de la publication de la version majeure suivante.
2023.11.4

Standard

12 mars 2024

Les clients peuvent désormais installer Data Movement gateway sur Red Hat 9.x ou sur toute distribution Linux correspondante et compatible.

Configuration de Data Movement gateway

Les commandes permettant d'arrêter et de démarrer le service Data Movement gateway et de vérifier son statut ont changé.

Commandes du service Data Movement gateway

  • Le type de données BOOLEAN, qui était mappé vers VARCHAR(1) dans Amazon Redshift, est désormais mappé vers BOOLEAN.
  • Les types de données BYTES et BLOB, qui étaient mappés vers VARCHAR(1) dans Amazon Redshift, sont désormais mappés vers VARBINARY (length).

Cette section répertorie les nouvelles bases de données, versions de bases de données et versions de pilotes prises en charge

  • Nouvelles versions et éditions de sources de données prises en charge

    Les versions de sources de données suivantes sont désormais prises en charge :

    • Base de données Azure pour MySQL - Serveur flexible (prise en charge via le connecteur source MySQL)
    • MariaDB 10.4 - 10.11 (auparavant 10.4 et 10.5)
  • Nouvelles plates-formes de données et éditions cibles prises en charge

    Les versions de cibles de données suivantes sont désormais prises en charge :

    • Base de données Azure pour MySQL - Serveur flexible (prise en charge via le connecteur cible MySQL)
    • Databricks : Databricks 13.3 LTS et Serverless SQL Warehouse
  • Nouvelle version de pilote SAP HANA prise en charge

    Les clients possédant une source SAP HANA qui souhaitent installer Data Movement gateway sur Red Hat Linux 9.x doivent installer le pilote 64 bits ODBC SAP HANA version 2.0.19 ou une version ultérieure.

Cette section fournit des informations sur les versions des bases de données en fin de prise en charge.

  • Arrêt de la prise en charge des versions de sources de données suivantes :

    • Oracle 11.x
    • SAP HANA 1.0
  • L'installation de Data Movement gateway sans fournir de mot de passe serveur ne permettait pas de configurer les URL client et proxy en une seule commande.
  • Le déplacement de données d'une source de données (application SaaS) Salesforce déclenchait un grand nombre d'avertissements redondants affectant les performances de chargement des données.
  • Lors de la récupération des modifications d'une source de données d'une application SaaS, en cas d'erreur lors de la récupération des modifications d'une des tables, cette table était suspendue et retirée du pipeline. Désormais, en cas d'erreur, la tâche tente de récupérer les modifications jusqu'à trois reprises avant de suspendre la table.
Déterminé lors de la publication de la version majeure suivante.
2023.5.16

Standard

9 janvier 2024

Nous continuons de développer les cibles prises en charge pour les projets Replicate dans Qlik Cloud Data Integration ; en plus d'Amazon S3, vous pouvez désormais sélectionner Azure Data Lake Storage (ADLS) et Google Cloud Storage (GCS) pour la livraison dans des lacs de données au format de fichier Parquet, JSON ou CSV.

  • La connexion à IBM DB2 for LUW échoue lorsque la taille des fichiers nécessaires à la connexion (comme le certificat du client SSL et le fichier KeyStore) dépasse 4 Ko.

  • L'installation du pilote DB2 échouait lors de l'utilisation de l'utilitaire d'installation de pilote.

7 septembre 2024

2023.5.15

Standard

12 décembre 2023

Microsoft Fabric vient s'ajouter à la liste, qui s'allonge constamment, des entrepôts de données pouvant être utilisés comme cibles dans des projets de pipeline de données.

Mise à jour de la version du pilote Snowflake dans l'utilitaire d'installation de pilote.

7 septembre 2024

2023.5.10

Standard

31 octobre 2023

Vous pouvez utiliser une connexion privée pour garantir la sécurité et la conformité de votre trafic de données. Cela simplifie la gestion réseau et la sécurité de votre VPC (Virtual Private Cloud - cloud privé virtuel) sans besoin d'ouvrir des ports de pare-feu entrants, des appareils proxy ni des tables de routage. Qlik Cloud Data Integration prend déjà en charge les connexions privées aux cibles de pipeline de données Snowflake, Microsoft SQL Server et Amazon S3. Avec cette version, les clients peuvent également utiliser des connexions privées lors du déplacement de données vers Databricks, Microsoft Azure Synapse, Google BigQuery et Amazon Redshift.

  • Toutes les sources de données basées sur PostgreSQL - Prise en charge de types de données multirange : Les types de données multirange suivants sont désormais pris en charge avec toutes les sources de données basées sur PostgreSQL (sur site et dans le cloud).

    • INT4MULTIRANGE
    • INT8MULTIRANGE
    • NUMMULTIRANGE
    • TSMULTIRANGE
  • Source de données AWS Aurora Cloud for PostgreSQL - Prise en charge du rôle non-super-utilisateur : L'utilisateur spécifié dans le connecteur PostgreSQL n'a plus besoin d'avoir le rôle de super-utilisateur pour pouvoir déplacer des données d'une source de données AWS Aurora Cloud for PostgreSQL. Cela s'avère particulièrement utile pour les entreprises disposant de stratégies de sécurité appliquées à l'ensemble de l'entreprise qui les empêchent d'accorder l'accès de superutilisateur à des utilisateurs non-privilégiés.

Les clients qui déplacent des données d'une source de données Microsoft Azure SQL (MS-CDC) peuvent désormais utiliser une base de données Geo Replica.

Intégration de données Qlik Cloud prend désormais en charge la lecture de données depuis des colonnes chiffrées et des espaces de stockage (tablespaces) chiffrés Oracle dans le cadre du processus CDC.

Intégration de données Qlik Cloud prend désormais en charge les clients des régions DE et UK.

Cette section répertorie les nouvelles versions de pilotes et de bases de données prises en charge.

  • Nouvelles versions de sources de données prises en charge. Les versions de sources de données suivantes sont désormais prises en charge :

    • Microsoft SQL Server 2022
    • Oracle 21c
    • PostgreSQL 15.x
    • DB2 13.1 (avec IBM DB2 for z/OS)
    • IBM DB2 for iSeries 7.5
  • Nouvelles versions de plates-formes de données cibles prises en charge. Les versions de cibles de données suivantes sont désormais prises en charge :

    • Databricks (Cloud Storage) : Databricks 12.2 LTS et Databricks SQL Serverless
  • Versions de pilotes. Les versions de pilotes ODBC suivantes sont désormais prises en charge :

    • IBM Data Server Client 11.5.8 for IBM DB2 for z/OZ et IBM DB2 for LUW
    • Simba ODBC driver 3.0.0.1001 for Google Cloud BigQuery
    • MySQL ODBC Unicode Driver 64-bit 8.0.32

Les clients qui migrent des données depuis ou vers Microsoft SQL Server doivent mettre à niveau leur pilote ODBC SQL Server à la version 18.x ou une version ultérieure. Notez que, si vous continuez à utiliser SQL Server ODBC Driver 17.x, vous risquez de rencontrer des erreurs de données. La mise à niveau du pilote peut s'effectuer via l'utilitaire d'installation de pilote ou manuellement. Pour des instructions, voir Configuration du pilote.

Cette section fournit des informations sur les versions des bases de données en fin de prise en charge.

  • Fin de la prise en charge de certaines versions de sources de données. Arrêt de la prise en charge des versions de sources de données suivantes :

    • PostgreSQL 10
    • MySQL 5.6
    • MariaDB 10.3
  • Fin de la prise en charge de certaines versions de plates-formes de données cibles. Arrêt de la prise en charge des versions de cibles de données suivantes :

    • Databricks 9.1 LTS

7 septembre 2024

2022.11.74

Standard

15 août 2023

Nous privilégions le cloud, qui permet une innovation et une adoption rapides. Cependant, cela ne veut pas dire que nous nous limitions au cloud. Dans le cadre de notre engagement continu en faveur de l'amélioration de la valeur à long terme que nous offrons à nos clients, nous sommes ravis d'annoncer le lancement d'un nouveau cas d'utilisation de Replicate lors de la création de projets de données. Le nouveau cas d'utilisation Replicate s'ajoute à la fonction existante qui permet de créer des pipelines de données pour l'ensemble de vos besoins d'intégration de données, comme la modernisation des entrepôts de données.

Le projet Replicate prend en charge la réplication de données en temps réel de sources de données prises en charge dans une cible prise en charge.

À partir de cette dernière version, la première cible prenant en charge la réplication de données en temps réel est Microsoft SQL Server. Outre la prise en charge de Microsoft SQL Server sur site, les fournisseurs de cloud suivants sont pris en charge :

  • Sur site
  • Amazon RDS
  • Google Cloud
  • Microsoft Azure (Microsoft Azure Managed Instance et Microsoft Azure Database)

Les clients qui migrent des données vers Microsoft Azure Synapse Analytics doivent mettre à niveau leur pilote ODBC SQL Server à la version 18.x ou une version ultérieure. Notez que, si vous continuez à utiliser SQL Server ODBC Driver 17.x, vous risquez de rencontrer des erreurs de données. La mise à niveau du pilote peut s'effectuer via l'utilitaire d'installation de pilote ou manuellement. Pour des instructions, voir Configuration du pilote.

Une nouvelle option Charger les données de la source a été lancée. Elle permet aux utilisateurs de lire leurs données directement depuis la source lors du Chargement complet, au lieu d'utiliser les données en cache.

Pour plus d'informations sur cette option, y compris des cas d'utilisation, voir la section Paramètres de dépôt temporaire.

Data Movement gateway 2022.11.74 inclut des certificats CA mis à jour, nécessaires pour l'authentification du client Qlik Cloud. Les certificats CA mis à jour fournissent également une prise en charge pour les régions Irlande et Francfort. Par conséquent, les utilisateurs disposant de clients Qlik Cloud en Irlande ou à Francfort qui souhaite utiliser Intégration de données Qlik Cloud doivent effectuer une mise à niveau vers cette version.

Les tâches de dépôt temporaire de données provenant d'une source Oracle échouaient parfois lorsqu'une table volumineuse contenait des colonnes non utilisées ou non prises en charge ou des colonnes LOB non répliquées.

31 avril 2024

2022.11.70

Standard

28 juin 2023

Dans les précédentes versions, lors de l'installation de clients SAP, les utilisateurs devaient exécuter la commande "source arep_login.sh". À partir de cette version, il n'est plus nécessaire d'exécuter cette commande.

Cette version inclut des certificats CA mis à jour, nécessaires pour l'authentification du client Qlik Cloud.

  • En cas d'échec et de récupération automatique d'une tâche Replicate sur Data Movement gateway, l'état récupéré n'était pas communiqué à la ressource de données de dépôt temporaire dans Qlik Cloud.

  • Le chiffrement de bout en bout de Data Movement gateway n'était pas activé par défaut et était contrôlé par des indicateurs de temps d'exécution.
15 septembre 2023

2022.11.63

Standard

2 mai 2023

Cette version intègre un utilitaire d'installation de pilote qui supprime le besoin d'installer et de configurer manuellement des pilotes. Le nouvel utilitaire accélère la procédure d'installation tout en réduisant considérablement le risque d'erreurs de la part de l'utilisateur. Lorsque l'utilitaire est exécuté, le pilote requis est automatiquement téléchargé, si possible, et installé. S'il n'est pas possible de télécharger le pilote (par exemple, les pilotes DB2 nécessitent une connexion), il vous suffit de télécharger le pilote, de le copier dans un dossier dédié sur le poste de la passerelle Déplacement de données et d'exécuter l'utilitaire.

Pour un exemple d'utilisation de l'utilitaire d'installation de pilote pour installer un pilote PostgreSQL, voir Conditions préalables requises.

Le connecteur Snowflake prend désormais en charge les caractères émoticônes de 4 octets.

Le connecteur PostgreSQL peut désormais déplacer des données depuis Azure Database for PostgreSQL - Flexible Server.

Le connecteur PostgreSQL peut désormais déplacer des données depuis Cloud SQL for PostgreSQL.

Cette version inclut la prise en charge des nouvelles versions de sources de données suivantes :

  • PostgreSQL 14
  • DB2 (for IBM DB2 for z/OS) 12.1
  • IBM DB2 for z/OS 2.5

Databricks 11.3 LTS

Les versions de sources de données suivantes ne sont plus prises en charge :

  • DB2 (for IBM DB2 for z/OS) 11
  • PostgreSQL 9.6
  • Microsoft SQL Server 2012
  • MariaDB 10.2

Cette version résout les problèmes suivants :

  • Source de données Oracle : Lors de l'arrêt et de la reprise d'une tâche, la tâche échouait parfois avec une erreur “Failed to set stream position on context” (Échec de définition de la position du flux dans le contexte).
  • Source d'application SAP : Les modifications n'étaient pas capturées lors de la tâche de dépôt temporaire.

15 septembre 2023

2022.5.13

Standard

19 octobre 2022

Version initiale

2 août 2023

Désinstallation de Data Movement gateway

Pour désinstaller Data Movement gateway, exécutez la commande suivante :

rpm -e <installation package name>

Exemple :

rpm -e qlik-data-gateway-data-movement-2023.11-1.x86_64

Si vous ne connaissez pas le nom du package, exécutez :

rpm -qa | grep qlik

Note AvertissementLa désinstallation de Data Movement gateway entraînera l'échec de l'ensemble des tâches utilisant actuellement la passerelle de données.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !