Árvore de páginas

Introdução 

Damos o nome de SQLiteDB para a utilização do TOTVS | SQLite como Banco de Dados principal de um ambiente.

Através da configuração adequada, é possível acessar os dados armazenados pelo TOTVS | SQLite através da RDD TOPCONN e demais funções específicas do TOTVS | DBAccess (funções TC*).

Para isto, basta ajustar o ambiente configurado no TOTVS | Application Server para utilizar o TOTVS | SQLite como banco de dados. Internamente, a RDD "TOPCONN" e as funções TC* passam a utilizar o TOTVS | SQLite como se ele estivesse sendo acessado por um TOTVS | DBAccess, mas sem a necessidade deste. Afinal, o TOTVS | SQLite está "embedado" do TOTVS | Application Server.


O uso do SQLiteDB foi projetado para aplicações de instância única e mono-usuário, devido a restrições implícitas do TOTVS | DBAccess.

Configuração 

Partindo de um ambiente com a chave RPODB configurada como SQL, troque sua configuração para SQLITE e acrescentar as configurações exibidas no trecho abaixo, respeitando os valores definidos para cada chave:

[Environment]
RPODB=SQLITE
DBDataBase=SQLITE
DBServer=localhost
DBPort=7890
DBALIAS=SYSTEM

Comportamentos e detalhes técnicos

  • Neste ambiente a utilização da RDD "TOPCONN" para a criação e abertura de tabelas vai internamente utilizar o TOTVS | SQLite como Banco de Dados, sem precisar de um TOTVS | DBAccess.
  • A maioria das funções específicas do TOTVS | DBAccess (TCLink(), TCCanOpen(), TCDelFile(), entre outras) são utilizadas da mesma forma, porém o Banco de Dados em uso será o TOTVS | 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 

    Erro ao processar a macro "excerpt-include"

    User 'null' does not have permission to view the page.

    , embora internamente não existe uma conexão TCP, mas sim um contexto de uso equivalente à uma conexão.
  • A função TCGetDB() neste ambiente retorna a string "SQLITE"
  • O arquivo em disco que será utilizado como o banco do TOTVS | SQLite chama-se "system.db", e será criado automaticamente em uma pasta chamada DB_SYS (também criada automaticamente a partir do RootPath do ambiente).
  • Adicionalmente, será criada uma pasta chamada DB_TMP a partir do RootPath, para uso de arquivos temporários do TOTVS | SQLite.
  • É possível alterar as pastas citadas acima através das configurações DBSysPathDBTmpPath, que devem informar um caminho completo de onde os arquivos de dados devem ser criados.

Estas pastas podem ser especificadas fora do RootPath do ambiente, mas nenhuma outra instância de TOTVS | 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 TOTVS | 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.


Checkpoint

Na mesma pasta onde fica o arquivo de dados do TOTVS | SQLite (arquivo system.db) são criados dois arquivos auxiliares para uso do "core" do TOTVS | 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 Dadosm mas ainda não 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 para efetivar a gravação dos dados do arquivo, removendo ele do disco naturalmente. 

Restrições


Algumas restrições de funcionalidade e comportamentos aplicam-se a este ambiente, são elas:

  • Acesso concorrente: A implementação do SQLITEDB suporta multi-thread – múltiplos processos executando operações na mesma base de dados. Porém, o possui limitações implícitas para operações de DDL – como por exemplo alteração de estrutura de tabelas, criar e apagar 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 não podem ser feitas concorrentemente com outras operações quaisquer, exigindo acesso exclusivo. Neste contexto, o encapsulamento de acesso ao Banco de Dados feito internamente pelo TOTVS | Application Server fecha tabelas e queries em execução, de forma transparente, para conseguir realizar a operação, e restaura sob demanda os contextos de execução.
  • Transacionamento: Embora as funções de transacionamento esteja disponíveis, internamente elas estão configuradas por default para não serem executadas. É possível habilitar o suporte a transacionamento explícito, porém isso somente é recomendável se a aplicação em questão usar apenas um contexto de conexão e apenas uma processo. Uma vez que exista uma transação aberta, nenhum outro processo consegue abrir outra transação, ou realizar qualquer instrução de DDL no TOTVS | SQLite – como por exemplo criar ou apagar uma tabela ou índice. 
  • Integração com DBAccess: Como a configuração do ambiente indica que a RDD TOPCONN e funções TC* devem usar o internamente o TOTVS | SQLite, este ambiente não carrega a biblioteca cliente do TOTVS | DBAccess  (DBAPI), e portanto (ainda) não é capaz de conectar com um outro SGDB enquanto utilizar o ambiente RPODB=SQLITE. 
  • Tabelas Temporárias : O 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 TOTVS | 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 endereçando a tabela temporária através da RDD TOPCONN


Acesso por ferramentas externas

O formato de um Database é aberto e multi-plataforma, e existem diversas ferramentas de consulta e DDL/DML que atuam sobre estes tipos de arquivo. Sendo assim, existem 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 é uma prerrogativa da implementação do , 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 em questão está sendo usada pelo , pois a aplicação externa pode interferir e prejudicar a operação do TOTVS | SQLite