- Versionshinweise
- Bevor Sie beginnen
- Erste Schritte
- Verwalten des Zugriffs
- Arbeiten mit Prozess-Apps
- Erstellen von Prozess-Apps
- Laden von Daten
- Hochladen von Daten
- Retrieving the SQL Server database parameters
- Setting up a SQL Server account for data upload using an extractor
- Loading data using Theobald Xtract Universal
- Systemanforderungen
- Konfigurieren des DataBridgeAgent
- Configuring CData Sync
- Hinzufügen eines benutzerdefinierten Connectors zu DataBridgeAgent
- Verwenden von DataBridgeAgent mit dem SAP Connector für den Purchase-to-Pay Discovery Accelerator
- Verwenden von DataBridgeAgent mit SAP Connector für den Order-to-Cash Discovery Accelerator
- Anpassen von Prozess-Apps
- Datentransformationen
- Bearbeiten von Datentransformationen in einer lokalen Umgebung
- Setting up a local test environment
- SQL differences between Snowflake and SQL Server
- Designing an event log
- Structure of transformations
- Tips for writing SQL
- TemplateOne-App-Vorlage
- Purchase-to-Pay-App-Vorlage
- Order-to-Cash-App-Vorlage
- Basic troubleshooting guide
SQL differences between Snowflake and SQL Server
In a local development environment, transformations are run on SQL Server, while Snowflake is used in Process Mining Automation Suite. Although most SQL statements will work both on SQL Server and Snowflake, there can be slight differences in syntax, which may lead to different return results.
So schreiben Sie SQL-Anweisungen, die auf beiden Datenbanksystemen funktionieren:
- Schreiben Sie Feldnamen in doppelte Anführungszeichen, z. B.
Table."Field"
. -
Verhindern der Verwendung von SQL-Funktionen, die sich in Snowflake und SQL Server unterscheiden, z. B.
string_agg()
undlistagg()
.Daspm_utils
-Paket enthält eine Reihe von Funktionen, die für beide Datenbanktypen funktionieren, siehe Mehrere Datenbanken. Anstatt beispielsweisestring_agg()
oderlistagg()
zu verwenden, führtpm_utils.string_agg()
zu demselben Verhalten für beide Datenbanken. Wennpm_utils
nicht die gewünschte Funktion enthält, sollte eine Chinja-Anweisung erstellt werden, um sicherzustellen, dass die richtige Funktion für jede Datenbank aufgerufen wird.
pm_utils.concat()
. Dies führt zu den gleichen Ergebnissen für SQL Server und Snowflake.
pm_utils.concat("This is a nice string", null)
= "This is a nice string"
Das Verketten von Zeichenfolgen sollte nicht mit Operatoren wie +
oder ||
erfolgen, da sie sich für beide Datenbanken unterscheiden (Snowflake verwendet ||
und SQL Server verwendet +
). Auch die Standardfunktion concat()
hat auf beiden Systemen ein unterschiedliches Verhalten:
SQL-Server |
Snowflake |
---|---|
null werden ignoriert und als leere Zeichenfolge behandelt.
|
null führen dazu, dass das gesamte Ergebnis null ist.
|
Die Sortierung wird in Snowflake und SQL Server unterschiedlich gehandhabt.
... order by "Attribute_1" desc, "Attribute_2" ...
SQL-Server |
Snowflake |
---|---|
null werden standardmäßig zuerst sortiert (aufsteigend)
|
null werden standardmäßig als letztes sortiert (aufsteigend)
|
SQL-Server |
Snowflake |
---|---|
Großbuchstaben werden wie erwartet sortiert (AaBbCc) |
Sortiert zuerst nach Großbuchstaben, dann nach Nicht-Großbuchstaben (ABCabc) |
Wenn Sie nach den Werten „A“ und „A“ gruppieren, wird dies in SQL Server als ein Wert angesehen, in Snowflake jedoch als zwei verschiedene Werte. Daher wird das Trimmen empfohlen, wenn Ihre Daten dieses Problem verursachen können.
Table."Field" = "Some_value"
und Table."Field" = "SOME_VALUE"
dasselbe Resultset in SQL Server zurückgeben, aber möglicherweise zwei verschiedene Resultsets in Snowflake.
Es wird empfohlen, das Verhalten Ihrer lokalen SQL Server-Datenbank so zu ändern, dass es dem Verhalten von Snowflakes entspricht, um Probleme zu vermeiden. Dies kann erreicht werden, indem die Datenbanksortierung auf einen Wert festgelegt wird, bei dem die Groß-/Kleinschreibung beachtet wird.