- Notas de versão
- Introdução
- Integrações
- Como trabalhar com aplicativos de processo
- Como trabalhar com painéis e gráficos
- Como trabalhar com gráficos de processo
- Trabalhando com Descubra modelos de processo e Importar modelos BPMN
- Showing or hiding the menu
- Informações de contexto
- Exportar
- Filtros
- Envio de ideias de automação ao UiPath® Automation Hub
- Tags
- Datas de conclusão
- Comparar
- Verificação de conformidade
- Análise de causa raiz
- Simulação de Potencial de Automação
- Iniciar um projeto do Task Mining a partir do Process Mining
- Triggering an automation from a process app
- Exibição de dados do processo
- Criação de aplicativos
- Carregamento de dados
- Personalização de aplicativos de processo
- Modelos de apps
- Recursos adicionais
- Edição de transformações de dados em um ambiente local
- Setting up a local test environment
- Métricas personalizadas de tempo de transferência
- SQL differences between Snowflake and SQL Server
- Configuration settings for loading input data
- Designing an event log
- Estendendo a ferramenta de extração SAP Ariba
- Recursos de desempenho
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 CloudTM. 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.
Para escrever instruções SQL que funcionem em ambos os sistemas de banco de dados:
- Escreva os nomes dos campos entre aspas duplas, por exemplo
Table."Field"
. -
Evite o uso de funções SQL diferentes no Snowflake e no SQL Server, por exemplo
string_agg()
elistagg()
.O pacotepm_utils
vem com um conjunto de funções que funcionam em ambos os tipos de banco de dados, consulte Diversos bancos de dados. Por exemplo, em vez de usarstring_agg()
oulistagg()
,pm_utils.string_agg()
resultará no mesmo comportamento para ambos os bancos de dados. Sepm_utils
não contiver a função desejada, uma instrução Jinja deverá ser criada para garantir que a função correta seja chamada em cada banco de dados.
pm_utils.concat()
. Isso produzirá os mesmos resultados para SQL Server e Snowflake.
pm_utils.concat("This is a nice string", null)
= "This is a nice string"
A concatenação de strings não deve ser feita com operadores como +
ou ||
, pois são diferentes para ambos os bancos de dados (Snowflake usa ||
e SQL Server usa +
). Além disso, a função concat()
padrão tem comportamento diferente em ambos os sistemas:
SQL Server |
Snowflake |
---|---|
null os valores serão ignorados e tratados como uma string vazia.
|
null os valores farão com que todo o resultado seja null .
|
A classificação é tratada de forma diferente no Snowflake e no SQL Server.
... order by "Attribute_1" desc, "Attribute_2" ...
SQL Server |
Snowflake |
---|---|
null o padrão será ordenado primeiro (crescente)
|
null o padrão será classificado por último (crescente)
|
SQL Server |
Snowflake |
---|---|
as maiúsculas são classificadas como esperado (AaBbCc) |
primeiro classifica por maiúsculas, depois por não maiúsculas (ABCabc) |
Quando você agrupa por valores “A“ e “ A“, isso é visto como um valor no SQL Server, mas como dois valores diferentes no Snowflake. Portanto, o corte é recomendado se seus dados puderem causar esse problema.
Table."Field" = "Some_value"
e Table."Field" = "SOME_VALUE"
retornarão o mesmo conjunto de resultados no SQL Server, mas possivelmente dois conjuntos de resultados diferentes no Snowflake.
É recomendável alterar o comportamento do banco de dados local do SQL Server para corresponder ao comportamento do Snowflakes, a fim de evitar problemas. Isso pode ser feito definindo o agrupamento do banco de dados para um valor que diferencia maiúsculas de minúsculas.