Tipos suportados
Os seis motores de base de dados que uma app pode ligar, os campos de cada um, o que cada motor sabe fazer, e as ferramentas para criar e alterar tabelas sem sair da plataforma.
Ao criar um datasource, o campo Tipo decide tudo o resto: os campos de ligação que o formulário mostra, os marcadores de parâmetros que o SQL usa, e o que a plataforma te deixa criar nessa base (vistas, procedimentos, triggers). Esta página percorre os seis tipos, um a um.

Vista rápida
| Tipo | Liga a | Porto por omissão | Particularidades |
|---|---|---|---|
| PostgreSQL | Servidor PostgreSQL | 5432 | Interruptor Usar SSL |
| MySQL | Servidor MySQL | 3306 | Interruptor Usar SSL |
| MariaDB | Servidor MariaDB | 3306 | Interruptor Usar SSL |
| MS SQL Server | Servidor Microsoft SQL Server | 1433 | Encrypt, Trust server certificate, TLS legado, Timeout de query (s) |
| Oracle | Base Oracle | — (vai na connect string) | Um único campo Connect string |
| SQLite | Base de dados local, em ficheiro | — (não há servidor) | Sem credenciais; a base vive com a app |
Nota
Os cinco primeiros são bases de dados externas — servidores teus, que a plataforma contacta pela rede com as credenciais que registares. O SQLite é o caso especial: uma base de dados em ficheiro, guardada com a própria app.
PostgreSQL, MySQL e MariaDB
Os três partilham o mesmo formulário:
| Campo | O que é |
|---|---|
| Host | Endereço do servidor (nome ou IP) |
| Porto | Vem preenchido com o do motor (5432 ou 3306) |
| Database | O nome da base de dados dentro do servidor |
| Utilizador | A conta com que a plataforma se liga |
| Password | A password dessa conta — nunca volta a ser mostrada |
| Usar SSL | Liga a cifra da ligação, se o servidor a exigir ou suportar |
Dica
Usa uma conta de base de dados dedicada à app, com privilégios apenas sobre o que a app precisa. Todas as queries — de APIs, scripts e consola — correm com esta conta, e os privilégios dela são o tecto do que a app consegue fazer.
MS SQL Server
Além de Host, Porto (1433), Database, Utilizador e Password, o SQL Server traz quatro opções próprias:
| Opção | Para que serve |
|---|---|
| Timeout de query (s) | Tempo máximo de cada query, em segundos (vem a 30). Sobe-o se tens stored procedures longas — abaixo disso, elas morrem a meio com erro de timeout. |
| Encrypt | Cifra a ligação (vem ligado). |
| Trust server certificate | Aceita o certificado do servidor sem o validar — típico em servidores internos com certificado próprio. |
| TLS legado (SQL Server antigo) | Ver abaixo. |
O próprio formulário explica quando ligar o último: "Liga o TLS legado se a ligação falhar a um SQL Server antigo (2008/2012) com erros de SSL/TLS — permite o handshake com cifras/protocolos antigos (implica confiar no certificado do servidor)."

Dica
Ligação a um SQL Server 2008/2012 a falhar com mensagens de SSL? É quase sempre isto: liga TLS legado e testa de novo. A opção baixa o nível de segurança só desta ligação — não afecta os outros datasources.
Oracle
O Oracle dispensa host e porto separados — a morada vai toda num campo:
| Campo | O que é |
|---|---|
| Connect string | No formato host:port/service_name — ex.: ora.interno.exemplo.pt:1521/CRMPROD |
| Utilizador | O schema/conta Oracle com que a plataforma se liga |
| Password | A password dessa conta |

Nota
Em Oracle, ligar-se como um utilizador é entrar no schema dele — as tabelas desse schema aparecem na árvore de objectos sem prefixo.
SQLite — a base de dados que vive com a app
O SQLite é o tipo para dados que pertencem à app: protótipos, demos, uma base pequena que não justifica um servidor. Não há Host, Porto, Utilizador nem Password — há um ficheiro, e é a plataforma que o guarda:
- Escolhe SQLite no campo Tipo.
- Opcionalmente, usa Importar base de dados (opcional) para enviar um
ficheiro
.db,.sqliteou.sqlite3que já tenhas. - Carrega em Criar. Como diz a ajuda do campo: "Sem ficheiro, é criada uma base de dados vazia. O ficheiro fica guardado com a app — não há caminhos a indicar."

Três comportamentos a saber:
- Criar não tem Testar ligação — o ficheiro ainda não existe, não há nada para testar. O botão aparece depois de gravar, na edição.
- Editar nunca troca o ficheiro — o ficheiro é o datasource; editares a ligação não cria uma base nova nem apaga dados.
- Eliminar o datasource despede-se dos dados — ao contrário dos tipos externos, aqui a base vive com a app.
O que cada motor sabe fazer
A plataforma só te oferece o que o motor suporta — as opções que não existem num motor não aparecem no menu dele. O mapa:
| Capacidade | PostgreSQL | MySQL | MariaDB | MS SQL Server | Oracle | SQLite |
|---|---|---|---|---|---|---|
| Vistas | Sim | Sim | Sim | Sim | Sim | Sim |
| Funções / procedimentos | Sim | Sim | Sim | Sim | Sim | Não |
| Triggers — momentos | BEFORE, AFTER, INSTEAD OF | BEFORE, AFTER | BEFORE, AFTER | AFTER, INSTEAD OF | BEFORE, AFTER, INSTEAD OF | BEFORE, AFTER, INSTEAD OF |
| Trigger com vários eventos de uma vez | Sim | Não (um por evento) | Não (um por evento) | Sim | Sim | Não |
| Trigger desenhado no canvas visual | Sim | Sim | Sim | Sim | Sim | Não (só SQL) |
| Alterar tipo/nulidade de coluna existente | Sim | Sim | Sim | Sim | Sim | Não |
| Campo Schema (opcional) nos objectos | Sim | — | — | Sim | Sim | — |
Nota
No SQL Server não existe BEFORE — o equivalente é INSTEAD OF. E no SQLite, mudar o tipo de uma coluna existente obriga a recriar a tabela; a opção não aparece.
Criar e alterar objectos (DDL)
Não precisas de outra ferramenta para trabalhar a estrutura da base: o menu ⋯ de cada datasource no painel Dados cria objectos, e a árvore edita os existentes. Em todos os casos a plataforma gera o SQL para o motor do datasource e executa-o a sério na base de dados.
| Acção | O que faz |
|---|---|
| Nova tabela | "Define as colunas — geramos o CREATE TABLE para o motor e executamos." Colunas com tipo, Permite NULL, Chave primária (PK), Auto-incremento, e nome amigável para as apps. |
| Editar estrutura (numa tabela) | "Altera colunas e índices — gera e executa o ALTER / CREATE INDEX correspondente." Também cria e elimina índices. |
| Nova vista | Escreves o SQL da vista e executa. |
| Nova função / procedimento | Escreves o SQL e executa (nos motores que os suportam). |
| Novo trigger | Dados iniciais no modal; o fluxo constrói-se a seguir no canvas visual. |
| Actualizar objectos | Relê a estrutura da base — usa depois de mudanças feitas fora da plataforma. |

Atenção
Isto é DDL verdadeiro, na tua base de dados verdadeira — um DROP ou um ALTER aqui é tão definitivo como executado em qualquer outro cliente SQL. E só resulta se o Utilizador da ligação tiver privilégios para criar e alterar objectos.
A Consola SQL
No fundo do ecrã Modelo de cada datasource vive a Consola SQL: escreve à esquerda, carrega em Executar, e os resultados aparecem em tabela (até 500 linhas), com filtros por coluna. O editor autocompleta com as tabelas e colunas do datasource, e o Ver dados de qualquer tabela da árvore abre a consola já com um select pronto.

A consola é de administradores, e as operações de escrita ficam registadas na auditoria — os detalhes estão na página Testar a ligação e segurança.
Marcadores de parâmetros por motor
Quando escreves SQL em scripts, os valores passam numa lista à parte — nunca colados na frase — e cada motor tem a sua sintaxe de marcador:
| Motor | Marcadores | Exemplo |
|---|---|---|
| PostgreSQL | $1, $2, … |
select * from contas where cidade = $1 |
| MySQL / MariaDB | ? |
select * from contas where cidade = ? |
| MS SQL Server | @p1, @p2, … |
select * from contas where cidade = @p1 |
| Oracle | :1, :2, … |
select * from contas where cidade = :1 |
| SQLite | ? |
select * from contas where cidade = ? |
Dica
Nos passos SQL das APIs não precisas desta tabela: escreves :nomeDoArg e
a plataforma trata da conversão para o motor escolhido. Em Oracle, evita
passar datas como parâmetro — prefere o literal, ex.:
TO_DATE('2026-06-25','YYYY-MM-DD').