SQLITEDB

Introdução 

Damos o nome de SQLITEDB para a utilização do SQLite como Banco de Dados principal de um ambiente, onde é possível acessar os dados do SQLite através da RDD TOPCONN e demais funções específicas do DBAccess (TC_*). Na prática, você pega um programa originalmente escrito para trabalhar com um SGDB homologado pelo DBAccess, e configura o seu ambiente no TOTVS Application Server para usar o SQLITE como banco de dados, e internamente o Driver/RDD TOPCONN e as funções de execução de statements e queries ( TCSqlEXec, TCGenQry... ) usam internamente o SQLITE, como se ele estivesse sendo acessado por um DBAccess – mas sem o DBAccess, afinal o SQLITE já está dentro do TOTVS Application Server. 

Configuração 

Basta partir de um ambiente com RPODB=SQL ( TTT?.RPO), e trocar a configuração de RPODB=SQL para RPODB=SQLITE, e acrescentar as configurações abaixo, com os valores estipulados abaixo na seção de configuração do ambiente:

DBDataBase=SQLITE
DBServer=localhost
DBPort=7890
DBALIAS=SYSTEM

Comportamento 

Desta forma, neste ambiente a utilização da RDD "TOPCONN" para a criação e abertura de tabelas vai internamente usar o SQLITE como Banco de Dados, sem precisar de um DBAccess. A maioria das funções específicas do DBAccess, como TCLink(), TCCanOpen(), TCDelFile() entre outras são utilizadas da mesma forma, porém o Banco de Dados em uso será o SQLITE. Algumas funcionalidades não foram implementadas, como por exemplo as funções para stored procedures e virtualização de índices. A função TCLink() deve ser chamada como se o Banco de Dados em uso fosse acessado pelo DBAccess, embora internamente não existe uma conexão TCP, mas sim um contexto de uso equivalente a uma conexão. A função TCGetDB() neste ambiente retorna a string "SQLITE"

O arquivo em disco que será usado como o Banco SQLITE chama-se "system.db", e será criado automaticamente em uma pasta chamada DB_SYS, criada também automaticamente a partir do RootPath do ambiente. Também será criada uma pasta adicional chamada "db_tmp" a partir do RootPath, para uso de arquivos temporários do SQLITE. Podemos alterar as pastas acima através das configurações DBSysPath e DBTmpPath – que devem informar um path completo de onde os arquivos de dados devem ser criados, e estas pastas podem ser especificadas fora do RootPath do ambiente – MAS nenhuma outra instância de Application Server deve ser configurada para acessar os mesmos arquivos da mesma pasta, sob pena de corrompimento dos dados e comportamentos inesperados. Uma base do SQLITE somente pode ser acessada por um serviço do TOTVS Application Server, e sempre apontando para um PATH na máquina local, jamais para um compartilhamento de rede.

LocalFiles

O driver de arquivos locais – referenciado em AdvPL como "DBFCDX" – pode ser configurado neste cenário também para o SQLITE. Porém, esta configuração ( LOCALFILES=SQLITE) usa o SQLITE como um porte de acesso de RDD de disco em modo de compatibilidade ISAM, sendo assim cada arquivo criado com a RDD DBFCDX será um arquivo SQLITE no disco a partir do Rootpath do ambiente. Dadas as restrições naturais de processo e contexto únicos impostos pelo uso do RPODB=SQLITE neste ambiente, a configuração LOCALFILES=SQLITE é naturalmente adequada para este cenário. 

Arquivo de LOG transacional (extensão .wal)

Na mesma pasta onde fica o arquivo de dados do SQLITE (arquivo system.db) são criados dois arquivos auxiliares para uso do "core" do SQLITE. Um deles possui a extensão "WAL" (Write Ahead Log). Este arquivo contém as inclusões e alterações feitas no Banco de dados mas ainda n"ao efetivadas para  o arquivo de dados oficial. A cada sequencia de operações durante o uso do sistema é feita uma "rápida parada" para efetivar o log transacional. Estas paradas são chamadas de "Checkpoint". Sempre que o serviço do TOTVS Application Server for finalizado, ou nenhum outro processo AdvPL possua alguma tabela ou conexão aberta, um checkpoint é implicitamente executado ara efetivar os dados do arquivo, removendo ele do disco naturalmente. 

Comportamento - Multi-Thread

A implementação do SQLITEDB suporta multi-thread – múltiplos processos executando operações na mesma base de dados. Porém, o SQLITE possui limitações implícitas para operações de DDL – como por exemplo alteração de estrutura de tabelas, criação e drop de tabelas e índices, onde o nível de bloqueio é mais restritivo do que um Banco de Dados relacional — operações de alteração de definição e de objetos no SQLITE não podem ser feitas concorrentemente com outras operações quaisquer, exigindo acesso exclusivo. Neste contexto, como o encapsulamento de acesso ao Banco de Dados feito pelo TOTVS Application Server fecha internamente as tabelas e queries em execução, de forma transparente, para conseguir realizar a operação, e restaura sob demanda os contextos de execução. 

Restrições - Transacionamento 

Embora as funções de transacionamento esteja disponíveis, internamente elas estão configuradas por default para não transacionar o SQLITE. É possível habilitar o suporte a transacionamento explícito para SQLITE, porém isso somente é recomendável se a aplicação em uso usar apenas um contexto de conexão e em apenas uma thread AdvPL. Uma vez que exista uma transação aberta, nenhum outro processo consegue abrir outra transação, ou realizar qualquer instrução de DDL no SQLITE – como por exemplo criar ou dropar uma tabela ou índice. 

Restrições - Integração com DBAccess

Como a configuração do ambiente indica ao TOTVS Application Server que a RDD TOPCONN e funções TC* devem usar o SQLITE embutido no TOTVS Application Server, este ambiente não carrega a biblioteca client do DBAccess ( DBAPI), e portanto (ainda) não é capaz de conectar com um SGDB via DBAccess enquanto utilizar o ambiente RPODB=SQLITE. Por hora, se houver a necessidade de ler ou gravar dados entre tabelas SQLITE e tabelas de um SGDB acessado pelo DBAccess, isto somente é possível criando dois ambientes, um para o SQLITE e outro para o DBACCESS, e criando um processo em cada ambiente para a troca de informações – usando IPC por exemplo. 

Restrições - Tabelas Temporárias 

O DBAccess possui um mecanismo de criação de tabelas temporárias nos bancos de dados homologados, e a mesma API e endereçamento foram implementadas também para o SQLITE como Base de Dados principal. Porém, (ainda) não é permitido fazer uma Query de uma tabela da base de dados com um JOIN de uma tabela temporária, bem como rodar queries sobre uma tabela temporária. Por hora sua implementação atende apenas aos requisitos de acesso em modo ISAM – usando as funções AdvPL endereçando a tabela temporária com a RDD TOPCONN.

Restrição - Acesso por ferramentas externas

O formato de um Database SQLITE é aberto e multi-plataforma, e existem diversas ferramentas de consulta e DDL/DML que atuam sobre estes tipos de arquivo. Sendo assim, várias ferramentas externas suportam manipular este tipo de arquivo. Porém, nenhuma deve ser usada para algo diferente de CONSULTAR informações. Fazer DDL ou DML nas bases de dados SQLITE é uma prerrogativa da implementação do TOTVS Application Server, mesmo tais operações sejam realizadas em uma cópia da tabela, apartada e acessada em modo exclusivo. Se utilizadas ferramentas externas para consulta de dados, evite utilizar a ferramenta de consulta enquanto a base SQLITE em questão está sendo usada pelo TOTVS Application Server, pois a aplicação externa pode interferir no funcionamento do core do SQLITE do TOTVS Application Server, e prejudicar a operação da aplicação.