Comportamentos e detalhes técnicos
Desta forma, neste ambiente a utilização da RDD "TOPCONN" para a criação e abertura de tabelas vai internamente usar o
como Banco de Dados, sem precisar de um
Inclusão de trecho |
---|
| DBAccess |
---|
| DBAccess |
---|
nopanel | true |
---|
|
. A maioria das funções específicas do
Inclusão de trecho |
---|
| DBAccess |
---|
| DBAccess |
---|
nopanel | true |
---|
|
, como TCLink(), TCCanOpen(), TCDelFile() entre outras são utilizadas da mesma forma, porém o Banco de Dados em uso será o
. 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
Inclusão de trecho |
---|
| tecen:DBAccess |
---|
| tecen:DBAccess |
---|
nopanel | true |
---|
|
, embora internamente não existe uma conexão TCP, mas sim um contexto de uso equivalente a uma conexão. A função
Inclusão de trecho |
---|
| teces:AdvPL |
---|
| teces:AdvPL |
---|
nopanel | true |
---|
|
TCGetDB() neste ambiente retorna a string "
SQLITE"
O arquivo em disco que será usado como o Banco do
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 do
. Podemos alterar as pastas acima através das configurações
DBSysPath e
DBTmpPath – que devem informar um caminho 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
Inclusão de trecho |
---|
| Application Server |
---|
| Application Server |
---|
nopanel | true |
---|
|
deve ser configurada para acessar os mesmos arquivos da mesma pasta, sob pena de corrompimento dos dados e comportamentos inesperados. Uma base do
somente pode ser acessada por um serviço do
Inclusão de trecho |
---|
| Application Server |
---|
| Application Server |
---|
nopanel | true |
---|
|
, e sempre apontando para um PATH na máquina local, jamais para um compartilhamento de rede.
Na mesma pasta onde fica o arquivo de dados do
(arquivo system.db) são criados dois arquivos auxiliares para uso do "core" do
. 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ã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
Inclusão de trecho |
---|
| Application Server |
---|
| Application Server |
---|
nopanel | true |
---|
|
for finalizado, ou nenhum outro processo
Inclusão de trecho |
---|
| teces:AdvPL |
---|
| teces:AdvPL |
---|
nopanel | true |
---|
|
possua alguma tabela ou conexão aberta, um
checkpoint é implicitamente executado ara efetivar os dados do arquivo, removendo ele do disco naturalmente.
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, como o encapsulamento de acesso ao Banco de Dados feito pelo
Inclusão de trecho |
---|
| Application Server |
---|
| Application Server |
---|
nopanel | true |
---|
|
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.