- Notas relacionadas
- Antes de empezar
- Primeros pasos
- Integraciones
- Trabajar con apps de proceso
- Trabajar con paneles y diagramas
- Trabajar con diagramas de proceso
- Trabajar con modelos de proceso Descubrir e Importar modelos BPMN
- Showing or hiding the menu
- Información del contexto
- Exportar
- Filtros
- Envío de ideas de automatización a UiPath® Automation Hub
- Etiquetas
- Fechas límite
- Comparar
- Comprobación de conformidad
- Análisis de causa raíz
- Simular el potencial de automatización
- Iniciar un proyecto de Task Mining desde Process Mining
- Triggering an automation from a process app
- Ver datos del proceso
- Creación de aplicaciones
- Cargar datos
- Personalizar apps de proceso
- Publicar aplicaciones de proceso
- Plantillas de la aplicación
- Recursos adicionales
- Etiquetas y fechas de vencimiento listas para usar
- Editar transformaciones de datos en un entorno local
- Setting up a local test environment
- Métricas personalizadas de tiempo de procesamiento
- SQL differences between Snowflake and SQL Server
- Configuration settings for loading input data
- Designing an event log
- Ampliar la herramienta de extracción de SAP Ariba
- Características de rendimiento
SQL differences between Snowflake and SQL Server
En un entorno de desarrollo local, las transformaciones se ejecutan en SQL Server, mientras que Snowflake se utiliza en Process Mining Automation CloudTM Public Sector. Aunque la mayoría de las declaraciones SQL funcionarán tanto en SQL Server como en Snowflake, puede haber ligeras diferencias en la sintaxis, lo que puede dar lugar a resultados de retorno diferentes.
Para escribir instrucciones SQL que funcionen en ambos sistemas de bases de datos:
- Escriba los nombres de los campos entre comillas dobles, por ejemplo
Table."Field"
. -
Evite el uso de funciones SQL que son diferentes en Snowflake y SQL Server, por ejemplo,
string_agg()
ylistagg()
.El paquetepm_utils
viene con un conjunto de funciones que funcionan en ambos tipos de bases de datos, consulta Varias bases de datos. Por ejemplo, en lugar de usarstring_agg()
olistagg()
, elpm_utils.string_agg()
dará como resultado el mismo comportamiento para ambas bases de datos. Sipm_utils
no contiene la función deseada, entonces se debe crear una instrucción Jinja para asegurarse de que se llama a la función correcta en cada base de datos.
pm_utils.concat()
. Esto producirá los mismos resultados tanto para SQL Server como para Snowflake.
pm_utils.concat("This is a nice string", null)
= "This is a nice string"
La concatenación de cadenas no debe realizarse con operadores como +
o ||
, ya que son diferentes para ambas bases de datos (Snowflake usa ||
y SQL Server usa +
). Además, la función concat()
estándar tiene un comportamiento diferente en ambos sistemas:
Servidor SQL |
Snowflake |
---|---|
Los valores
null se ignorarán y se tratarán como una cadena vacía.
|
Los valores
null harán que el resultado completo sea null .
|
La clasificación se gestiona de forma diferente en Snowflake y en el servidor SQL.
... order by "Attribute_1" desc, "Attribute_2" ...
Servidor SQL |
Snowflake |
---|---|
null se ordenará de forma predeterminada (ascendente)
|
null se ordenarán por defecto en último lugar (ascendente)
|
Servidor SQL |
Snowflake |
---|---|
las mayúsculas se ordenan como se esperaba (AaBbCc) |
primero ordena por mayúsculas, luego por no mayúsculas (ABCabc) |
Cuando se agrupan por valores "A" y "A", esto se ve como un valor en SQL Server, pero como dos valores diferentes en Snowflake. Por lo tanto, se recomienda recortar si sus datos pueden causar este problema.
Table."Field" = "Some_value"
y Table."Field" = "SOME_VALUE"
devolverán el mismo conjunto de resultados en SQL Server, pero potencialmente dos conjuntos de resultados diferentes en Snowflake.
Se le recomienda cambiar el comportamiento de su base de datos local de SQL Server para que coincida con el comportamiento de Snowflake, a fin de evitar cualquier problema. Esto se puede lograr estableciendo la colación de la base de datos en un valor que distinga entre mayúsculas y minúsculas.