Importer depuis SQL

Description

Importe le résultat d’une requête SQL exécutée sur une base de données externe dans une table de projet PlaidCloud. La requête s’exécute sur la base de données distante ; seul le jeu de résultats est transféré dans PlaidCloud.

Diffère de Importer les tables de base de données externe en ce que vous écrivez vous-même le SQL, ce qui est utile pour les jointures, filtres ou agrégations complexes que vous voulez faire exécuter par la base de données source avant que les données n’arrivent dans PlaidCloud.

Paramètres d’importation

Importer une table SQL

Source et cible

Connexion à la base de données

Pour établir une Connexion à la base de données, consultez Connexions de données PlaidCloud

Table cible

La sélection de la cible pour les importations est limitée aux tables, car les vues ne contiennent pas de données sous-jacentes.

Option dynamique

L’option dynamique permet de spécifier une table à l’aide de texte, y compris des variables. C’est utile dans les workflows pilotés par des variables, où les références de tables et de vues sont relatives aux variables spécifiées.

Exemple qui utilise la variable current_month pour pointer dynamiquement vers la table cible :

legal_entity/inputs/{current_month}/ledger_values

Option statique

Lorsque vous souhaitez une table précise comme cible de l’importation, laissez la case Dynamique décochée et sélectionnez la table cible.

Si la table cible n’existe pas, sélectionnez le bouton Créer pour créer la table à l’emplacement souhaité.

L’Explorateur de tables est toujours disponible pour toute sélection de table. Cliquez sur le bouton Explorateur de tables à droite de la sélection de table : une fenêtre Explorateur de tables s’ouvre.

Requête SQL

Dans cette section, écrivez la requête SQL qui renvoie les données voulues.

Détection du type de colonne

Les importations SQL peuvent tenter de deviner le type de données pendant le chargement, ou définir toutes les colonnes au type Text. Définir les types de données dynamiquement peut être plus rapide si les données sont propres, mais peut poser problème dans certains cas.

Par exemple, si la plupart des données semblent numériques mais que certaines sont du texte, l’étape peut tenter de les définir comme numériques, ce qui provoque des problèmes de chargement dus à des types de données incompatibles. Un problème peut aussi survenir avec un code produit numérique de 16 chiffres, par exemple : les zéros de tête seraient supprimés, ce qui donnerait un nombre au lieu d’un code à 16 chiffres.

Définir toutes les données en texte exige en revanche une étape Extract ultérieure pour convertir au type approprié, comme des dates ou des valeurs numériques, toutes les données qui ne doivent pas rester du texte.

Dépannage

Symptôme	Cause probable
L’étape a pris nettement plus de temps que d’habitude (jusqu’à une demi-heure de plus environ) sans que rien d’autre ne change dans votre requête, votre connexion ou le volume de données	Le worker en arrière-plan qui exécutait l’importation a été interrompu en cours de route (un redémarrage ou une éviction côté plateforme, et non un problème de votre workflow), et la plateforme a relancé pour vous l’importation de la table. La nouvelle tentative ne démarre qu’une fois l’interruption détectée, ce qui explique le temps supplémentaire.
L’étape s’est quand même terminée avec succès après ce délai	La nouvelle tentative remplace entièrement le contenu de la table, de sorte que le résultat est identique à celui d’une seule exécution propre : il n’y a rien d’autre à vérifier ni à refaire.
L’étape échoue avec « has already been attempted and cannot be safely re-run »	Pour une étape Import SQL, ce refus ne se produit plus : une interruption en cours d’exécution est relancée. Vous le verrez toujours, par conception, pour la restauration d’une archive de projet ou le chargement d’une dimension, où une nouvelle exécution créerait un doublon au lieu de remplacer quoi que ce soit. Ouvrez un ticket de support si vous le voyez depuis une étape Import SQL elle-même.