Configurando Conexões de Bancos de dados

Por default, o Action.NET usa um gerenciador de banco de dados SQL embutido SQLite, para os Historiadores de Tags e de Alarmes. Você pode configurar outros bancos de dados externos, tais como o Microsoft SQL Server, Oracle, ou outros. Se você tem a expectativa de que estes historiadores vão necessitar armazenar grandes quantidades de dados e exigir maior robustez e características cliente/servidor, você deve considerar desde a implantação inicial o uso de um banco de dados externo.

Ao usar o banco de dados integrado, o Action.NET cria automaticamente o arquivo de banco de dados. Ao usar bancos de dados externos, o arquivo do banco de dados deve ser criado pelos utilitários pelo uso do gerenciador escolhido. No entanto, o Action.NET pode criar as tabelas no banco de dados, disponibilizado.
Você pode usar também bancos de dados externos como fonte de dados em sua aplicação para exibir dados como informações do cliente ou de seus produtos ou para configurar sistemas de receitas.

O botão SQL Query Builder possibilita a chamada a um aplicativo que é uma ferramenta para a construção de consultas SQL. Veja nesta documentação a a secção Visual SQL Query Builder com detalhes sobre a utilização deste aplicativo.

Você precisa estar logado como administrador no Action.NET, para configurar o login e a senha do banco de dados.

Para configurar um banco de dados externo:

1. Vá para Edit> Datasets > DBs.

2. Clique em Create New.

   • É mostrada a janela de Criar Nova Conexão de banco de dados.

3. Digite ou selecione as informações, conforme necessário

1. Clique OK.

   • O banco de dados é adicionado como uma nova linha na tabela.

2. Digite ou selecione as informações, na nova linha da tabela, conforme necessário, para concluir a configuração do banco de dados

1. Se você estiver usando um novo banco de dados externo para o historiador de tags ou de alarmes, mude o nome dos bancos de dados existentes TagHistorian or AlarmHistorian para outros, e em seguida, mude o nome da nova configuração de banco de dados para TagHistorian ou AlarmHistorian.

   • Para os bancos de dados de historiador de tags ou de alarmes, a configuração dos nomes dos banco de dados nesta aba devem ser TagHistorian ou AlarmHistorian. Você não pode ter dois bancos de dados com o mesmo nome.

2. Continue adicionando tantos bancos de dados quantos que você precisa.

   • As bases de dados que você criar estarão disponíveis para uso na aba Tags> Historian, na confecção de telas e para os scripts.

   • Se necessário, clique com o botão direito em uma linha para cortar, copiar, colar ou excluir a linha.

Para acessar o Manager do Servidor de banco de dados

O botão DBAdmin é utilizado para ativar o aplicativo manager do servidor de banco de dados utilizado para o banco de dados externo. 

String de Conexão do Historiador e Alarmes

A string de conexão para TagHistorian e AlarmHistorian possui parâmetros que podem ser configurados para evitar perda de dados. Eles são:

• Data Source: O caminho do servidor e a instância que terá os bancos de dados.

• Catálogo Inicial: O nome do banco de dados que será utilizado.

• Store and Forward: habilitar esta opção fará com que o sistema armazene os dados localmente se a comunicação com o banco de dados for perdida e encaminha os dados para sincronização assim que a conexão for restabelecida.

• Keep the local copy: Habilitar esta opção fará com que o sistema armazene um banco de dados local com os mesmos dados que foram armazenados no banco de dados principal. O sistema usará o banco de dados interno para armazená-lo, e o arquivo pode estar localizado na mesma pasta em que o projeto está.

Formas de Armazenamento do Historian usando SQL (Dataset-DB)

 O processo de historian passa por dois tipos de eventos de armazenamento, o Trigger e o TagChange, e existem dois formatos possíveis de armazenamento o "Standard" e o "Normalized".

 No formato "Standard" tanto o evento de Trigger quanto de TagChange irão gerar uma única row a ser inserida no banco com Timestamp e todos os tags configurados na tabela. Quando usar eventos por Trigger o timestamp é do trigger, no entanto quando usar evento de TagChange, a row terá o timetsamp do TagChange (tag que mudou de valor), podendo ter mais de um tag modificado nesse mesmo timestamp, consequentemente em uma única row. Diversos TagChanges de tags diferentes com timestamp diferentes irão dar origem a múltiplas rows, cada row contendo TODOS os tags configurados, e o timestamp específico do TagChange que deu origem a essa inserção.

 No formato "Normalized" a row terá somente TimeStamp, ID do Tag e um único valor, portanto, um TagChange dará origem a uma row com o seu tag, e um trigger, dará origem a múltiplas rows, cada uma contendo um Tag configurado na tabela. No caso do TagChange o TimeStamp é o da mudança do tag, e no caso do Trigger todas as rows geradas por esse trigger terá o timestamp do trigger.

 Na configuração do Dataset-DB-TagHistorian, existem ainda algumas opções relacionadas a sincronismo de historian quando há falha na inserção:

1. Sem Store & Fwd: Salva direto no banco principal. Se "Normalized" salva em grupo as rows geradas a cada 5s por tabela, se “Standard” salva 1 row por tabela; Recuperação dos dados feita no banco principal

2. Com Store & Fwd e sem Keep Local: Tenta salvar no banco principal e em caso de falha, salva no banco local (que sempre será o SQLite). De tempos em tempos, a cada 5s, tenta MOVER do banco local (rows que foram inseridas em condições de falha) para o banco principal, em blocos máximos de 250 rows, passando tabela por tabela durante um período máximo de 4s, se não for possível passar em todas as tabelas, no próximo ciclo de 5s começará da próxima tabela pendente. Após o sucesso na COPIA das rows elas são deletadas do banco local, se o banco local estiver vazio ele é deletado. Recuperação dos dados feita no banco principal, se o acesso ao banco principal falhar a recuperação é feita no banco local(SQLite) com os dados que estiverem nesse banco local.

               Etapas da sincronização:

             i. Lê o banco local, para cada tabela (verificando a coluna NotSync que é usada para saber quais rows já foram sincronizadas) - select limit 250;

             ii. Salva no banco principal o grupo de rows-  insert ;

             iii. Deleta as rows do banco local que foram sincronizadas - delete SQLite

               (ainda existe mais algumas etapas nesse processo para garantir que a tabela no banco principal existe, se não existir será criada)

1.   Com Store & Fwd e com Keep Local: Salva no banco local (que sempre será o SQLite) e de tempos em tempos tenta COPIAR do banco local para o banco remoto, em blocos máximos de 250 rows, passando tabela por tabela durante um período máximo de 4s, se não for possível passar em todas as tabelas, no próximo ciclo de 5s começará da próxima tabela pendente. Após o sucesso na COPIA das rows as mesmas marcadas com NotSync para FALSE, somente as rows com NotSync em TRUE que serão copiadas para o banco remoto. Recuperação dos dados feita no banco local (SQLite).

               Etapas da sincronização:

               i. Lê o banco local, para cada tabela (verificando a coluna NotSync que é usada para saber quais rows já foram sincronizadas) - select limit 250;

               ii. Salva no banco principal o grupo de rows-  insert ;

               iii. Atualiza a coluna "NotSync" do banco local (SQLLite), para indicar que as rows foram sincronizadas - update SQLite

               (ainda existe mais algumas etapas nesse processo para garantir que a tabela no banco principal existe, se não existir será criada)

 É importante entender que usando Store & Fwd com Keep Local, os dados nunca serão armazenados diretamente no banco principal, serão armazenados imediatamente no banco local, e de tempos em tempos será sincronizado com o banco principal. Se houver muitas tabelas a serem sincronizadas, com muitos dados a serem sincronizados, dependendo da performance de inserção no banco principal e do banco local (SQLLite), pode ser que esse dado leve algum tempo para estar disponível no banco principal, mas após algum tempo ele estará disponível. Uma média de performance é que essas etapas de (i) a (iii) levem em torno de 1s por tabela.

Outra observação é com relação ao volume de dados, recomendamos usar SQLServer, Oracle e outros bancos mais robustos para grandes projetos com grande volume de dados, pois além de melhor performance, esses bancos suportam um alto volume de dados, e isso não vale para o SQLite. Consequentemente, usar o Keep Local para grandes projetos é desejar que o SQLite tenha replicado todo o histórico que está nesses grandes bancos. Essa funcionalidade funciona bem para modelos de dados menores, ou onde não se há necessidade de sincronização imediata com o banco de dados principal.

Accessando o Microsoft Excel

Para conectar-se à bancos de dados do Excel pode-se utilizar um driver ODBC, um DSN ODBC, ou OleDB. As seções a seguir apresentam detalhadamente os passos para configurar cada um destes métodos de conexão.

Criando as bases de dados ODBC

1. Selecione, e atribua um Nome para um intervalo de linhas e colunas na planilha. Isso permitirá que o software possa ler as informações como uma tabela.

2. Escolha um dos seguintes processos de nomeação para a sua versão do Microsoft Excel.

   • Para o Microsoft Office 2007:

     • Botão direito do mouse na área selecionada e escolha "Nome de um Range".

• Para o Microsoft Office 2003:

• No Microsoft Excel vá para "Insert > Name > Define".

• 

• Nomeie a seleção (por exemplo, "itensTable"). O arquivo Excel está agora pronto para o uso.

Métodos para se comunicar usando ODBC

Usando ODBC Microsoft Excel Driver:

1. No espaço de trabalho Datasets escolha a aba "DBs" e crie um novo Provider clicando em Create New

2. Selecione "Odbc Data Provider" no campo de "Provider"

3. No campo "Database" escolha "Microsoft Excel Database".

4. Clique Ok.

1. Uma nova linha será criada na tabela, clique a coluna "ConnectionString".

2. Aparece uma janela: nela entre com o caminho e o nome do arquivo no campo Extended Properties.

3. Opcionalmente clique o botão "Test" para assegurar-se que a conexão está OK.

Usando ODBC com um DSN:

1. No MS-Windos vá até "Painel de Controle" e selecione "Ferramentas Administrativas".

2. Faça um duplo clique sobre "Data Sources (ODBC)".

Na janela "Administrador de Fonte de Dados ODBC":

1. clique em Adicionar. Aparecerá outra janela solicitando para selecionar um "driver",

2. Selecione o "Microsoft Excel Driver (*.xls)". Clique em Concluir.

3. Clique Selecione Pasta de Trabalho e selecione o nome do arquivo Excel criado anteriormente.

4. Atribua um nome para a fonte de dados . exemplo:. "excelDatasource". Se pretender fazer acessos de escrita desmarque a opção "ReadOnly"

1. No espaço de trabalho Datasets escolha a aba DBs e crie um novo Provider clicando o botão Create New.

2. Na lista de opções "Odbc Data Provider" escolha "ODBC using DSN" e clique Ok.

3. Clique a coluna ConnectionString da nova linha criada na tabela de conexões e entre com DSN no campo DSN.

Utilizando OLEDB

1. No espaço de trabalho Datasets escolha a aba "DBs".

2. Selecione "OleDb data provider" e crie uma nova Conexão clicando em Create New

3. Selecione "Microsoft Excel Database" e então clique Ok.

4. Clique na coluna ConnectionString da nova linha criada, e entre com o caminho e o nome do arquivo Excel (.xls) no campo "DataSource"

Configurando acesso à Tabelas de BDs

Se você estiver usando um banco de dados externo como uma fonte de dados em sua aplicação, você pode especificar diretamente qual a tabela que vai utilizar a partir deste banco de dados.

Para configurar as tabelas de banco de dados:

1. Vá para Edit> Datasets >Tables.

2. Digite ou selecione as informações, conforme necessário.

• Continue adicionando tantas configurações de tabelas quantas você precisar.

Ler e escrever o conteúdo da tabela

O acesso, em tempo de execução, para o conteúdo da tabela é executado automaticamente quando a tabela é mapeada para um Objeto DataGrid, colocado em uma tela ou Relatório. Consulte "Configurando uma Janela DataGrid" .
Você também pode obter o conteúdo da tabela ou executar operações em tabelas, usando as propriedades de tempo de execução do objeto Dataset.Table, consulte +http://+ www.spinengenharia.com.br/help/an-2016/runtime/index.html .

Configurando consultas de banco de dados

Você pode configurar consultas para executar funções mais avançadas com instruções SQL para trabalhar com dados de bancos de dados externos.

Para configurar consultas à banco de dados:

1. Vá para Edit > Datasets > Queries.

2. Digite ou selecione as informações, conforme necessário.

• Continue adicionando tantas consultas quanto você precisa.

Obtendo o conteúdo da consulta

O acesso, em tempo de execução, ao conteúdo da tabela é executado automaticamente quando a consulta é mapeada para um Objeto DataGrid, colocado em uma Tela ou Relatório. Consulte "Configurando uma Janela DataGrid".
Você também pode obter o conteúdo da consulta ou executar operações de consulta à tabelas, usando as propriedades de tempo de execução do objeto Dataset.Table, consulte +http://+ www.spinengenharia.com.br/help/an-2016/runtime/index.html.

Configurando Arquivos para troca de dados

Você pode configurar arquivos para recuperar dados de um local qualquer de uma rede. acessível

Para configurar os arquivos de banco de dados:

1. Vá para Edit> Datasets > Files.

2. Digite ou selecione as informações, conforme necessário.

• Continue adicionando tantas configurações de arquivos quantas você precisar.

Objetos Runtime Datasets

O namespace Dataset é o ponto de entrada para todos os objetos relacionados com o módulo Datasets.
O objeto Dataset.DB. contém a lista de todos os bancos de dados e conexões configuradas e suas propriedades em tempo de execução.
O objeto Dataset.Table lista todas as tabelas configuradas e suas propriedades em tempo de execução.
O objeto Dataset.Query lista todas as consultas definidas e suas propriedades em tempo de execução.
O objeto Dataset.File lista os arquivos de troca de dados definidos e suas propriedades em tempo de execução.
Veja em {+}http://www.spinengenharia.com.br/help/an-2016/runtime/index.html+ .para a referência de programação completa em objetos de tempo de execução.