- Notes de publication
- Avant de commencer
- Démarrage
- Intégrations
- Travailler avec des applications de processus
- Travailler avec des tableaux de bord et des graphiques
- Travailler avec des graphiques de processus
- Travailler avec des modèles de processus Découvrir et importer des modèles BPMN
- Showing or hiding the menu
- Informations contextuelles
- Exporter (Export)
- Filtres
- Envoi d’idées d’automatisation au Automation Hub d’UiPath®
- Balises
- Dates d’échéance
- Comparer
- Vérification de la conformité
- Analyse des causes profondes
- Simulation du potentiel d’automatisation
- Triggering an automation from a process app
- Afficher les données de processus
- Création d'applications
- Chargement des données
- Personnaliser les applications de processus
- Introduction aux tableaux de bord
- Créer des tableaux de bord
- Tableaux de bord
- Gestionnaire de l’automatisation
- Input data
- Définition de nouvelles tables d'entrée
- Ajout de champs
- Ajouter des tables
- Configuration requise pour le modèle de données
- Affichage et modification du modèle de données
- Exportation et importation de transformations
- Modification et test des transformations de données
- Structure of transformations
- Fusion des journaux d'événements
- Tips for writing SQL
- Gestionnaire de processus
- Publication des tableaux de bord
- Modèles d'applications
- Ressources supplémentaires
- Balises et dates d'échéance prêtes à l'emploi
- Modification des transformations de données dans un environnement local
- Setting up a local test environment
- Métriques de temps de traitement personnalisées
- SQL differences between Snowflake and SQL Server
- Configuration settings for loading input data
- Designing an event log
- Extension de l’outil d’extraction SAP Ariba
- Caractéristiques de performances
Process Mining
SQL differences between Snowflake and SQL Server
Dans un environnement de développement local, les transformations sont exécutées sur SQL Server, tandis que Snowflake est utilisé dans Process Mining Automation Suite. Bien que la plupart des instructions SQL fonctionnent à la fois sur SQL Server et Snowflake, il peut exister de légères différences dans la syntaxe, ce qui peut entraîner des résultats de renvoi différents.
Pour écrire des instructions SQL qui fonctionnent sur les deux systèmes de base de données :
- Écrivez les noms de champ entre guillemets doubles, par exemple
Table."Field"
. -
Empêcher l'utilisation de fonctions SQL différentes dans Snowflake et SQL Server, par exemple
string_agg()
etlistagg()
.Le packagepm_utils
est livré avec un ensemble de fonctions qui fonctionnent sur les deux types de bases de données, voir Bases de données multiples. Par exemple, au lieu d'utiliserstring_agg()
oulistagg()
,pm_utils.string_agg()
entraînera le même comportement pour les deux bases de données. Sipm_utils
ne contient pas la fonction souhaitée, une instruction Jinja doit être créée pour s'assurer que la bonne fonction est appelée sur chaque base de données.
pm_utils.concat()
. Cela produira les mêmes résultats pour SQL Server et Snowflake.
pm_utils.concat("This is a nice string", null)
= "This is a nice string"
La concaténation de chaînes ne doit pas être effectuée avec des opérateurs tels que +
ou ||
, car ils sont différents pour les deux bases de données (Snowflake utilise ||
et SQL Server utilise +
). De plus, la fonction standard concat()
a un comportement différent sur les deux systèmes :
SQL Server |
Snowflake |
---|---|
Les valeurs
null seront ignorées et traitées comme une chaîne vide.
|
Les valeurs
null donneront au résultat entier la valeur null .
|
Le tri est géré différemment dans Snowflake et dans SQL Server.
... order by "Attribute_1" desc, "Attribute_2" ...
SQL Server |
Snowflake |
---|---|
null sera trié par défaut en premier (croissant)
|
null sera trié par défaut en dernier (croissant)
|
SQL Server |
Snowflake |
---|---|
les majuscules sont triées comme prévu (AaBbCc) |
trie d'abord par majuscules, puis par lettres non majuscules (ABCabc) |
Lorsque vous effectuez un regroupement par valeurs « A » et « A », cela est considéré comme une seule valeur dans SQL Server, mais comme deux valeurs différentes dans Snowflake. Par conséquent, le rognage est conseillé si vos données peuvent causer ce problème.
Table."Field" = "Some_value"
et Table."Field" = "SOME_VALUE"
renverront le même ensemble de résultats dans SQL Server, mais potentiellement deux ensembles de résultats différents dans Snowflake.
Il est conseillé de modifier le comportement de votre base de données SQL Server locale pour qu'il corresponde au comportement de Snowflakes, afin d'éviter tout problème. Cela peut être accompli en définissant le classement de la base de données sur une valeur sensible à la casse.