microsiga - programacao sql inter media rio

Programação SQL com SIGA Advanced / AP5

Programação SQL (Intermediário)

Com SigaAdvanced/ AP5

Windows NT Server , Windows Workstation, Windows 95/98 e SQL Server são marcas registradas da Microsoft Corporation. Banco de Dados Oracle é a marca registrada da Oracle Corporation. Banco de Dados Informix é a marca registrada da Informix Corporation. Banco de Dados Sybase é a marca registrada da Sybase Corporation. Banco de Dados UDB é a marca registrada da IBM.

Este material é de efeito didático/suporte e não pode ser reproduzido sem autorização da MicroSiga. CopyRight © 2000 Microsiga Software S.A.


Índice

1. Introdução ao ambiente Relacional 1.1. Objetivos 1.2. Conceitos Básicos de Banco de Dados 1.3. Conhecendo a estrutura de Armazenamento dos dados

1.3.1. LOG do Banco de dados 1.3.1.1. Controle Transacional 1.3.1.2. Segurança e Backup 1.3.1.3. Construindo Query’s evitando problemas com estouro da Área de

LOG 1.3.2. Área temporária do Banco de Dados

1.4. Normalização de Base de Dados 1.5. MER (Modelo Entidade Relacionamento) 1.6. Diferenças cruciais entre ambientes DBF e SQL

1.6.1. DBF – Trabalha de forma posicional com acesso compartilhado 1.6.2. SQL – Trabalha de forma relacional (Teoria dos conjuntos) e o acesso é de

forma centralizada

2. TopConnect 2.1. Informações gerais 2.2. Controle de tipo de dados ( Tabela TOP_FIELD ) 2.3. Opções de Visualizar os Eventos (Mensagens de Erros) 2.4. Sistema de controle de Registros

2.4.1. Portabilidade 2.4.2. Função da coluna R_E_C_N_O_

2.4.2.1. Limite de registros 2.4.2.2. Renumeração da coluna RECNO

2.4.3. Controle dos registros deletados (Coluna D_E_L_E_T_) 2.5. Constraints do Banco de dados que são criados automaticamente

2.5.1. Criação da Estrutura de tabelas 2.5.2. Índices 2.5.3. Defaults 2.5.4. Problemas com conteúdo Nulo

2.6. Manutenção do Banco de dados 2.6.1. Aumentando a performance executando a operação de PACK

2.7. DBFNTX x TopConnect 2.7.1. Índices de produção 2.7.2. Funções em chaves de índices 2.7.3. Índices condicionais 2.7.4. Chaves numéricas compostas 2.7.5. Expressões de filtro com funções e variáveis

2.8. Comandos 2.8.1. APPEND FROM 2.8.2. COPY TO 2.8.3. USE 2.8.4. BEGIN, COMMIT, ROLLBACK TRANSACTION


2.9. Funções

2.9.1. TCCANOPEN 2.9.2. TCCONTYPE 2.9.3. TCDELFILE 2.9.4. TCGETDB 2.9.5. TCLINK 2.9.6. TCQUERY 2.9.7. TCQUIT 2.9.8. TCSETCONN 2.9.9. TCSETFIELD 2.9.10. TCSPEXEC 2.9.11. TCSPEXIST 2.9.12. TCSQLERROR 2.9.13. TCSQLEXEC 2.9.14. TCSRVTYPE 2.9.15. TCUNLINK 2.9.16. TCCHKOBJ* 2.9.17. TCEXEERROR* 2.9.18. TCPGMEXE* 2.9.19. TCSYSEXE*

( * )Funções apenas para o TOPConnect rodando em servidores AS/400.

2.10. Performance 2.10.1. Otimizando seu código 2.10.2. Leitura Sequencial 2.10.3. O uso de filtros 2.10.4. Stored Procedures

2.11. Integração com outros aplicativos 2.11.1. Incluindo registros nas tabelas do SigaAdvanced / AP5 2.11.2. Excluindo registros ( Sempre Marcar ) 2.11.3. Vantagens e Desvantagens

3. Utilitário importante 3.1. Instalador de Stored Procedures no Banco de Dados


1. Introdução ao ambiente Relacional

1.1. Objetivos

Este curso tem como objetivo treinar e aperfeiçoar nossos analistas e parceiros quanto à confecção de programas específicos, em ambiente de trabalho com Base de Dados SQL

desta forma pretendemos aumentar a facilidade de manuseio dos componentes envolvidos tanto na análise e detecção de erros, e quais possíveis ações para saná-los, antes de recorrer ao suporte interno. Demonstraremos também como otimizar programas através da linguagem SQL em seus RDMAKES e futuras implementações para as próximas versões. Todos os tópicos mencionados poderão servir como base de consulta, para escrita de programas e resolução de problemas.

1.2. Conceitos Básicos de Banco de Dados

Os conceitos básicos dos Bancos de Dados relacionais são bem diferenciados dos conhecidos DBF´s. Estes conceitos básicos são úteis principalmente para saber responder eventuais perguntas que nossos clientes poderão efetuar sobre nosso sistema.

SQL quer dizer : Structured Query Language , que foi desenvolvido inicialmente pela IBM Corporation.

Um banco de dados não trabalha em função de registros, ou Arquivos como nós estamos acostumados a ver e fazer em linguagem de programação Clipper. o SQL utiliza a teoria de conjuntos conhecida pôr todos, que tem o objetivo de resolver os problemas dos usuários com comandos simples, chamados de query´s ( Requisição e Alteração de dados ), que utilizam basicamente 4 comandos : SELECT, INSERT, UPDATE, DELETE.

A primeira diferença entre o ambiente SQL e o DBF é o fato de criarmos uma área no disco (DATABASE) que o próprio banco se encarregara de administrar, no sentido de criar tabelas, índices, e todos os objetos envolvidos no sistema. A nomenclatura muda um pouco: ao invés de CAMPOS temos COLUNAS e ao invés de REGISTROS temos LINHAS.

Os índices trabalham de forma semelhante ao DBF, e são utilizados com duas finalidades : a de termos uma chave de acesso extremamente rápida, e de garantirmos uma chave única em uma tabela. A partir do momento que indicamos uma chave única em uma tabela, o próprio banco de dados passa a garantir que não existirá dados duplicados, sem a necessidade de programação para tal.

Também estarão ligados à uma tabela específica os Triggers, e as Foreign Keys ( Chaves Estrangeiras ). Em cada DataBase também estarão armazenadas as Stored Procedures, que são programas ou funções escritas como qualquer linguagem conhecida ( Clipper, Pascal etc.), só que no padrão ANSI / SQL.

Uma Trigger funciona como um gatilho, só que este é disparado não a cada campo alterado, e sim a cada Inclusão, Alteração ou Exclusão de uma linha da tabela. Os Triggers também são escritos como as Stored Procedures, ou seja, como um programa qualquer, que pode efetuar qualquer tipo de validação, atualização em outras tabelas, etc... Hoje não utilizamos no Siga Advanced nenhuma Trigger. Em alguns casos específicos em clientes, as mesmas poderão ser utilizadas.


Uma Foreign Key ( Chave Estrangeira ) é uma ligação entre tabelas que são criadas nas mesmas. São estas que garantem que nunca o Cliente “X” será excluído se o mesmo tiver movimentos ( Pedidos, Notas , Duplicatas Etc. ), também será garantido que nunca será incluído um Pedido de Vendas do Cliente “Y”, se o mesmo não existir. Este tratamento é feito diretamente pelo Banco de Dados, não necessitando qualquer codificação para isto.

O Siga Advanced/AP5 não trabalha hoje com o conceito de chaves estrangeiras no banco de dados.

O uso de um Banco de Dados SQL se faz necessário pela segurança dos dados e pela fácil recuperação dos mesmos por vários aplicativos como Siga Advanced / AP5 (TopConnect), Crystal Reports (ODBC), SigaEIS (BDE), Excel, etc.

Devido ao controle exercido sobre os dados a performance do banco acaba sendo prejudicada. Nos próximos tópicos estaremos demonstrando como melhorar e otimizar o SGDB (Sistema Gerenciador de Banco de Dados) para o melhor aproveitamento do sistema.

Para empresas que fazem uma grande utilização de banco de dados normalmente encontramos um profissional chamado DBA (Data Base Administrator), que tem a função de administrar o banco de dados, quanto a otimização, configuração, backups e segurança. Sabemos que na prática isto só funciona para empresas grandes, portanto temos que saber o mínimo possível de cada banco de dados para podermos identificar problemas e soluções que se adequam melhor à instalação do cliente.


1.3. Conhecendo a estrutura de Armazenamento dos dados

1.3.1. LOG do Banco de dados

1.3.1.1. Controle Transacional

Toda e qualquer operação de inclusão, alteração ou exclusão de registro é armazenada primeiramente na área de LOG. Se você faz uma inclusão no banco de dados de uma simples linha o mesmo garante a inclusão completa da linha (inserção de todas as colunas). Este fato é garantido pela definição no seu banco de dados de uma transação implicita. Agora vamos supor que você tenha uma operação que necessite que várias inclusões, alterações e exclusões realizadas só sejam efetuadas quando todas as operações tenham sido efetuadas com sucesso, caso contrário todas as operações devem ser canceladas.

Para definição de transação pelo usuário, normalmente se utilizam os comandos BEGIN e COMMIT , para definir início e fim de uma transação respectivamente. Para o cancelamento de um transação sem sucesso normalmente chamamos de ROLLBACK.

A área de LOG do Banco de dados é normalmente definida com 25% do tamanho da área de dados, mas este fator depende muito do número de usuários e a quantidade de transações realizadas em um determinado intervalo de tempo.

1.3.1.2. Segurança e Backup

Depois que uma transação é concluída com sucesso, não indica que a mesma estará sendo transferida para a área real dos dados. Este tramite de transferência é chamado de CheckPoint , este ponto é configuravél de acordo o SGDB utilizado. Para bancos de dados de maior escala, o processo de check point só é realizado após o Backup da área de LOG.

O LOG também é utilizado para fazer o backup de grande bancos de dados, guardando somente as alterações efetuados em um determinado intervalo de


tempo. Em clientes com base de dados pequenas, não utilizamos este tipo de recurso.

1.3.1.3. Construindo Query’s evitando problemas com estouro da Área de LOG

Conhecendo melhor o processo de gravação do banco de dados, percebemos que quanto menor for o número de operações de inserção, alteração e exclusão realizados dentro de uma transação melhor será a performance. Banco de dados que possuem grandes transações ocasionam problemas de deadlock. Realização de grandes updates na base de dados sem informar a clausula Where delimitando um intervalo de linhas a serem modificados. Na alteração e exclusão de linhas, precisamos tomar cuidado sempre com o intervalo de registros, se for o caso devemos executar várias vezes o mesmo blocos de comandos, mudando o intervalo de linhas, deste forma nunca teremos problemas com a área de LOG.

1.3.2. Área temporária do Banco de Dados

Esta área é de utilidade exclusiva do Banco de Dados, a mesma é utilizada em situações que o SGDB precisa gerar arquivo temporários para resolver as query’s que estamos solicitando, normalmente operações que exigem um determinada ordenação no resultado e não existe nenhum índice correspondente. Devemos tomar cuidado com query’s que necessitem área de trabalho, por que elas estarão perdendo mais tempo com i/o de disco.


1.4. Normalização de Base de Dados

A normalização de Base de dados tem como objetivo, definir a estrutura de entidades e seus atributos eliminando vários problemas de definição de armazenamento dos dados, que no momento da implementação serão percebidos. Existe até cinco níveis de normalização , mas somente utilizamos até o terceiro nível, atualmente não existe equipamento capaz de administrar um Banco de dados normalizado totalmente.

Com a pratica vamos perceber que a normalização é muito boa, mas o seu excesso gera problemas na programação, portanto temos sempre que fazer o máximo de normalização mas devemos estar consciente de quanto conseguiremos de vantagem com isto.

Existe casos que a desnormalização é uma das melhores soluções, para facilitar o desenvolvimento da aplicação ou para ganharmos performance.

A primeira forma normal diz que devemos definir a entidade e seus atributos, e destes atributos devemos definir um atributo chave de relação.

Ex.: Entidade = Pedido Atributos = Data Emissão, Produto , Quantidade ,etc.

Neste caso criaremos um campo código que define a sua chave principal de relacionamento, criaremos o Código. Nunca utilize mais de um coluna agregada com campo chave.(Este tipo de campo gera vários problemas na programação SQL)

A segunda forma normal diz que devemos subdividir os atributos que ocorrem mais de que uma vez, em uma outra entidade.(Esta entidade deve ter um campo chave, atendendo a primeira forma normal).

Ex.: Entidade = Pedido Atributos = Número do Pedido (Chave), Data de Emissão, etc.

Entidade = Itens do Pedido Atributos = Número, item (Número+item = chave), Quantidade, etc..

A terceira forma normal diz que devemos eliminar colunas que são concebidas por calculo de outras colunas de mesma entidade.

Ex.: Entidade = Pedido Atributos = Total do Pedido, Quantidade Total, etc.


1.5. MER (Modelo Entidade Relacionamento)

A partir da normalização podemos definir as relações estrangeiras de cada tabela, o MER é uma modelo gráfico que facilita a visualização do desenvolvimento de aplicativo. Além de apresentar todo o fluxo do dado dentro de um Banco de Dados. No caso do SigaAdvanced / AP5 você ter em mãos toda a estrutura do sistema é quase impossível, nestes casos o modelo é feito por módulo, e os pontos de integração são replicados em cada MER do correspondente módulo.

Sempre que possível ao desenvolver processos específicos no sistema procure desenhar o MER para detectar os problemas antes de sair desenvolvendo o produto.


1.6. Diferenças cruciais entre ambientes DBF e SQL

1.6.1. DBF – Trabalha de forma posicional com acesso compartilhado

Quando trabalhamos em um ambiente posicional, vários regras de programação e definição como apresentamos acima, não precisam ser cumpridas. E mesmo assim os processos são rápidos e de fácil manuseio. Este ambiente utiliza o modo Shared de controle de arquivos do sistema operacional, ou seja, o servidor destes arquivos é apenas um mero repositório de dados, nada é processado no Server. A desvantagem de utilizar estes arquivos normalmente é taxada pelo problemas gerados com erro em arquivos de índices e o nível de segurança muito baixo.

1.6.2. SQL – Trabalha de forma relacional (Teoria dos conjuntos) e o acesso é de forma centralizada

Agora quando trabalhamos com Base de Dados Relacional, a estrutura é totalmente diferente. Devemos atender várias exigências como controle de acesso ao dado que é muito mais restrito, a programação feita na aplicação deve ser bem otimizada para evitar requisições desnecessárias, o SGDB precisa utilizar processamento do Servidor para recuperar um dado solicitado pela aplicação. O Banco de Dados suporta grande capacidade de armazenamento de dados, garantindo sua integridade como um todo. A desvantagem do Banco de Dados é a necessidade de equipamentos potentes para atender a demanda.


2. TopConnect

2.1. Informações gerais

O TOPConnect foi desenvolvido em linguagem ‘C’ pela Microsiga e é utilizado hoje pelo SigaAdvanced / AP5 através da linguagem ADVPL (Advanced Protheus Language). Ele também pode ser utilizado por aplicações XBASE que queiram trocar a base de dados de DBF para SQL. Os gerenciadores de banco de dados hoje suportados são:

MS-SQL Server 6.5 e 7.0 ( MSSQL / MSSQL7 ) Oracle 7.3.4, 8.0.5 e 8i ( ORACLE ) IBM Universal Database 5.0 ( DB2 ) DB2/400 ( AS/400 ) Sybase Anywhere ( ANYWHERE / ANYSYB ) Sybase SQL-Server ( SYBASE ) Informix ( INFORMIX )

O TOPConnect é composto por um biblioteca replaceble database driver(RDD) e componentes de comunicação, sendo estes bibliotecas para aplicativos DOS e DLL's para aplicativos Windows. Estas bibliotecas devem ser linkeditadas com sua aplicação ADVPL para acessar o TOPConnect Server.

Alguns comandos e funções avançadas são disponibilizadas para que seu aplicativo possa usufruir de todos os benefícios da plataforma cliente servidor, que são apresentados logo em seguida.


2.2. Controle de tipo de dados ( Tabela TOP_FIELD )

Em um banco existem vários tipos de dados (CHAR, VARCHAR, FLOAT, NUMBER, etc.) porem para existir uma unicidade no código do Topconnect alguns dados são armazenados de forma diferente da definida na tabela SX3, porem a aplicação recebe o dado da forma como definido.

Os tipos de dados que são tratados atualmente são o seguintes:

Campos numéricos - são armazenados em variáveis do tipo FLOAT Campos Lógicos - são armazenados em variáveis do tipo CHAR (0 ou 1) Campos Data - são armazenados em variáveis do tipo CHAR com 8 bytes, no formato YYYYMMDD.

Os campo caracter não recebem nenhum tratamento.

A tabela TOP_FIELD contem a descrição de todos os campos NAO-CARACTER, para que o TopConnect faca a conversão dos dados quando da leitura dos mesmos. Ela é “alimentada” na criação de uma tabela.

Ex.: Tabela SA1010

A1_FILIAL C 2 A1_COD C 6 A1_LOJA C 2 A1_DESC C 1 A1_EMISSAO C 8 A1_VEND1 C 6 ... Ex.: Tabela TOP_FIELD

FIELD_TABLE FIELD_NAME FIELD_TYPE FIELD_PREC FIELD_DEC ------------------------------------------------------ -------------------------------- ------------------ ------------------ ----------------

dbo.SA1010 A1_COMIS P 5 2 dbo.SA1010 A1_DESC P 2 0 dbo.SA1010 A1_LC P 14 2 dbo.SA1010 A1_EMISSAO D 8 0 dbo.SA1010 A1_MCOMPRA P 17 2 dbo.SA1010 A1_METR P 7 2 dbo.SA1010 @@HAS_DFT_VAL@@ X 0 0 ... Neste exemplo vocês perceberão que na tabela TOP_FIELD só existe os campo numéricos, data e Lógico (no caso não existe nenhum usado pelo arquivo).

Alerta! : Se você for utilizar diretamente o Banco de dados você precisa estar ciente que um campo numérico é armazenado como um tipo float(MSSQL Server), Number(Oracle), etc. Por exemplo o valor 40,40 no banco pode estar armazenado como 40,39999999. Quando formos utilizar query’s você deve utilizar a função TCSETFIELD para resolver esta situação.(Veja função TCSETFIELD). Importante também salientar que qualquer modificação efetuada em arquivo SX3 diretamente, ou seja, sem utilizar o configurador, você pode Ter problemas com inconsistência de estrutura da tabela do Banco de Dados e TOP_FIELD contra o dicionário de dados. Para resolver este problema você deverá remover os dados da Tabela do Banco de dados, eliminar a tabela e deixa-la criar novamente e depois importar os dados via APPEND(Utilize SDU/CFG-AP5), ou você pode ajustar o dicionário de dados manualmente conforme estrutura no Banco de Dados.


2.3. Opções de Visualizar os Eventos (Mensagens de Erros)

A parte mais importante do Topconnect Manager é o gerenciamento das mensagens de erros, estas mensagens não são do TopConnect mas sim, de cada Banco de Dados, ou seja, se você obtiver um erro de Logon o erro que você receberá neste reporte, é exatamente a mesma mensagem que o Banco de Dados estaria informando se você utilizar um utilitário do próprio Banco para fazer o Acesso.

Na maioria dos problemas este logo de erros é o ponto principal para descobrir o que esta acontecendo, entre o Topconnect e o Banco de dados. Você só estará recebendo mensagens se o link entre o Banco de dados e o Topconnect estiver funcionando.

2.4. Sistema de controle de Registros 2.4.1. Portabilidade

Acreditamos que muitos já perguntarão por que da existência da coluna R_E_C_N_O_ no Banco de dados, mesmo os que não conhecem esta coluna tem como objetivo manter a portabilidade de uma Base DBF e Banco ADS para um Banco de Dados qualquer e também entre Banco de dados. Se você possui sua aplicação trabalhando em DBF , você pode porta-la independente de modificações para uma Base SQL, e se você já esta em uma base SQL do tipo MSSQL SQL Server e gostaria de porta-la para ORACLE, você pode fazer isto sem nenhum problema.

Alerta! : Se você possui programas específicos desenvolvidos (RDMAKES), você precisa que os mesmos estejam desenvolvidos nos padrões de compatibilidade exigidos pela Microsiga. Você verá mais adiante exemplos de programas e uma apresentação mais completa deste assunto.

2.4.2. Função da coluna R_E_C_N_O_

A Coluna R_E_C_N_O_, tem por objetivo principal guardar um número seqüencial de controle de registro, mais conhecido como ID (identificador). Este identificador é utilizado pela aplicação na pesquisa e posicionamento de registro.


Esta coluna não possui repetição, ela é sempre preenchida com o valor máximo da coluna R_E_C_N_O_ + 1 nas próximas inserções. Esta operação é feita pelo TopConnect , se você utiliza outros produtos que fazem inserção na Base de Dados do Sigaadvanced / AP5 você deve seguir as orientações do Capítulo Integrações com outros aplicativos.

2.4.2.1. Limite de registros

O limite de registros em uma tabela é de 2,147,483,648 , este número normalmente deve ser levado em consideração para as tabelas que recebem muita inserção de registro seguidas de muitas exclusões física do registro.

2.4.2.2. Renumeração da coluna RECNO

Quando os registros são deletados pelo sistema, os mesmos são apenas marcados, para exclusão física acontece em quando executamos a operação que conhecemos com Pack de registros. Após esta operação a coluna R_E_C_N_O_ não é renumerada. Não existe a necessidade de fazer a renumeração desta coluna, a não ser que você esteja perto de estourar o maior número possível nesta coluna. Neste caso você precisar extrair os dados do Banco de Dados para uma Base DBF e logo em seguida subir a Base novamente para o Banco de Dados, automaticamente a coluna R_E_C_N_O_ será ajustada.

2.4.3. Controle dos registros deletados (Coluna D_E_L_E_T_)

Toda exclusão de registro feita no Banco de Dados ou em qualquer plataforma do SigaAdvanced / AP5, só é feita logicamente, ou seja, o registro é marcado como excluído (delete), e esta marca é feita utilizando o campo chamado D_E_L_E_T_ , a mesma é preenchida com (*) Asterisco, caso contrário a coluna permanece com o conteúdo em branco.

Alerta! : Quando você utiliza o comando Set Delet on/off, o TopConnect estará tratando o dado para você, mas se você utiliza query’s para recuperação de dados você deverá tratar este coluna (Mais informações sobre o tratamento da coluna D_E_L_E_T_ será apresentado em exemplos de query’s em RDMAKES.


2.5. Constraints do Banco de dados que são criados automaticamente

2.5.1. Criação da Estrutura de tabelas

A estrutura de cada tabela do SigaAdvacend é criada automaticamente, tendo em vista a não existência da mesma no Banco de Dados. Para isto o usuário criado para o TopConnect acessar o banco de dados precisa Ter permissão de criação de tabelas, de preferência a permissão de DBA.

Neste momento a tabela TOP_FIELD estará sendo alimentada com todos os campos numéricos, datas e Lógicos.

Alerta! : Após o primeiro usuário fazer a conexão com o TopConnect e a parte de verificação de tabelas já foi executada, as referências de cada tabela selecionado no .mnu para abertura estarão em memória no TopConnect, portanto se por acaso alguma tabela for removida diretamente por um utilitário do Banco de Dados o TopConnect terá uma informação não coerente, você deve reiniciar o serviço do Topconnect (Parando / iniciando o Serviço).

2.5.2. Índices

Os índices são criados imediatamente após a criação da estrutura das tabelas. Os índices criados partem do arquivo de índices do SigaAdvanced / AP5, que é o arquivo SINDEX. Existe um índice que é criado apenas uma vez no momento em que a tabela é criada, este índice tem como formação do nome = <nome da tabela> + _RECNO , este índice e sempre composto da coluna R_E_C_N_O_ e não permite duplicidade.

Alerta!: Nunca remova os índices das tabelas, principalmente o índice RECNO que não será criado pelo TopConnect quando a tabela já existe. Se você criou um índice pelo SINDEX e depois percebeu que montou errado ou precisa elimina-lo, você precisa eliminá-lo do SINDEX e também do Banco de Dados.

2.5.3. Defaults

São constraints de validação de campos que não são informados, nos comandos de inserção e alteração, ou seja, se você não possui os defaults criados o Banco de Dados estará deixando estes campos com valor nulo. Os defaults são criados no momento da criação das tabelas.

Alerta!: Se você fizer qualquer operação de transferência via Banco de Dados que não transfira os Defaults, e logo em seguida você utilizar o sistema , estará correndo risco de inserir nulos na Base de Dados. Se isto acontecer você poderá Ter problemas com o TopConnect Server, ele poderá travar ou derrubar conexões com dados indevidos. A solução neste caso é utilizar o utilitário DEFAULT que esta disponível no site da Microsiga.


Este é um exemplo de script para MSSQL Server que o TopConnect estará disparando para o Banco de Dados quando a tabela SA1990 não existir no Banco.

CREATE TABLE [dbo].[SA1990] (

[A1_FILIAL] [varchar] (2) NULL , [A1_COD] [varchar] (6) NULL , [A1_LOJA] [varchar] (2) NULL , [A1_NOME] [varchar] (40) NULL , [A1_NREDUZ] [varchar] (20) NULL , [A1_TIPO] [varchar] (1) NULL ,

... [D_E_L_E_T_] [varchar] (1) NULL , [R_E_C_N_O_] [int] NULL

) GO

CREATE UNIQUE CLUSTERED INDEX [SA1990_RECNO] ON [dbo].[SA1990]([R_E_C_N_O_]) ON [PRIMARY] GO

ALTER TABLE [dbo].[SA1990] WITH NOCHECK ADD CONSTRAINT [DF__SA1990__A1_FILIA__06648751] DEFAULT (' ') FOR [A1_FILIAL], CONSTRAINT [DF__SA1990__A1_COD__0758AB8A] DEFAULT (' ') FOR [A1_COD], CONSTRAINT [DF__SA1990__A1_LOJA__084CCFC3] DEFAULT (' ') FOR [A1_LOJA], CONSTRAINT [DF__SA1990__A1_NOME__0940F3FC] DEFAULT (' ') FOR

[A1_NOME], CONSTRAINT [DF__SA1990__A1_NREDU__0A351835] DEFAULT (' ') FOR

[A1_NREDUZ], CONSTRAINT [DF__SA1990__A1_TIPO__0B293C6E] DEFAULT (' ') FOR [A1_TIPO],

... CONSTRAINT [DF__SA1990__D_E_L_E___6E57F396] DEFAULT (' ') FOR [D_E_L_E_T_], CONSTRAINT [DF__SA1990__R_E_C_N___6F4C17CF] DEFAULT (0) FOR [R_E_C_N_O_]

GO

CREATE INDEX [SA19901] ON [dbo].[SA1990]([A1_FILIAL], [A1_COD], [A1_LOJA], [R_E_C_N_O_]) ON [PRIMARY] GO

CREATE INDEX [SA19902] ON [dbo].[SA1990]([A1_FILIAL], [A1_NOME], [A1_LOJA], [R_E_C_N_O_]) ON [PRIMARY] GO

CREATE INDEX [SA19903] ON [dbo].[SA1990]([A1_FILIAL], [A1_CGC], [R_E_C_N_O_]) ON [PRIMARY] GO

CREATE INDEX [SA19904] ON [dbo].[SA1990]([A1_FILIAL], [A1_TEL], [R_E_C_N_O_]) ON [PRIMARY] GO


2.5.4. Problemas com conteúdo Nulo

Os Bancos de dados possuem o conteúdo nulo para todos os tipo de campos, mas o nosso sistema não os utiliza, se por ventura qualquer tabela tenha algumas linhas com alguma coluna com o valor nulo, isto pode provocar problemas que aparentam ser erro de índice, como ex. Você tem a tabela de pedidos que com os pedidos 000001,000002 e sua tabela por qualquer motivo não tem os contraints de defaults na coluna filial, agora você faz a inserção do pedido 0000003 o sistema irá apresentar um Browse ordenado por pedido da seguinte forma:

Considere a filial do arquivo de pedido de forma compartilhada.(Filiial=Branco)

Filial Pedido --------- ------------ Null 000003

000001 000002

Neste exemplo você percebe que o pedido 000003 aparece em primeira ordem, sendo o índice filial+pedido, ou seja, o valor nulo na tabela ASCII(Binary Order) aparece antes do caracter espaço em branco.

Este problema muitas vezes causa a impressão que o índice esta com problemas, por que a tela de Browse do Sigaadvanced / AP5 não apresenta a coluna filial.

Alerta!: Tabelas com conteúdo nulo, geram vários problemas no sistema, provavelmente deve gerar erros no TopConnect que o mesmo estará derrubando as conexões quando elas fizerem acesso a este tipo de conteúdo (nulo). Existe um utilitário que ajusta este problema se você o tiver, o mesmo esta disponível no site da Microsiga, com o nome de DEFAULT.exe


2.6. Manutenção do Banco de dados

2.6.1. Aumentando a performance executando a operação de PACK

Esporadicamente você deve fazer uma manutenção no Banco de dados, quanto as registros excluídos logicamente, os mesmo devem ser excluídos fisicamente, por que a sua existência em grande quantidade e de forma seqüencial gera um grave problema de performance no acesso aos dados.

Alerta!: Se você tiver este problema, utilize a operação de Pack do utilitário SDU na tabela que possui registros excluídos , ou utilize o programa fonte PACK para fazer esta operação em todas as tabelas.

Segue abaixo exemplo de fonte em RDMAKE, para fazer um pack em qualquer Banco de dados.

Exemplo de fonte em ADVPL para executar um Pack no Banco de Dados , esta rotina já prevê problema de estouro da área de LOG/RollBack de um Back de Dados

/* Função ³PACK ³ Autor ³ Emerson/Vicente ³ Data ³ 16.12.99 Descrição ³Rotina RDMAKE para eliminar os registros deletados do banco Uso ³RDMake <Programa.Ext> -w Exemplo ³RDMake Pack.prw */ @ 96,42 TO 323,505 DIALOG oDlg5 TITLE "Rotina de Pack" @ 8,10 TO 84,222 @ 91,168 BMPBUTTON TYPE 1 ACTION Execute(OkProc) @ 91,196 BMPBUTTON TYPE 2 ACTION Close(oDlg5) @ 23,14 SAY "Este programa ira fazer um pack em todos arquivos abertos pelo Advanced." ACTIVATE DIALOG oDlg5 Return nil

Function OkProc Close(oDlg5) Processa( {|| Execute(RunProc) } ) Return /* Funcao ³RunProc Descrição ³Executa o Processamento */ Function RunProc DbSelectArea("SX2") NrecnoSX2 := SX2->(Recno()) DbGoTop() ProcRegua(reccount()) While !Eof()

If Select(SX2->X2_CHAVE) > 0 cQuery := 'SELECT MAX(R_E_C_N_O_) RECNO FROM ' + SX2->X2_ARQUIVO dbUseArea(.T., "TOPCONN", TCGenQry(,,cQuery), 'CONT', .F., .T.) nCont := 1 While nCont <= CONT->RECNO

cQuery := "DELETE FROM "+SX2->X2_ARQUIVO cQuery := cQuery + " WHERE D_E_L_E_T_ = '*'" cQuery := cQuery + " AND R_E_C_N_O_ between "+Str(nCont)+" AND

"+Str(nCont+1024) nCont := nCont + 1024

TCSQLEXEC(cQuery) Enddo

DbSelectArea("CONT") DbCloseArea()

Endif DbSelectArea("SX2")

dbSkip() incproc() Enddo return


2.7. DBFNTX x TopConnect

2.7.1. Índices de produção

Todos os SGDB's utilizam o conceito de índices de produção portando uma aplicação que utilize o TOPConnect não necessita ter todos os índices abertos para que os mesmos sejam atualizados.

2.7.2. Funções em chaves de índices

Devido ao fato de os SGDB's não suportarem o uso de funções nos índices o TOPConnect não tem como suportar este tipo de implementação.

As únicas funções suportadas são STR e DTOS.

Para a criação de índices que contenham campos caracter e numéricos na chave apenas uma regra deve ser obedecida. A função STR deve obrigatoriamente receber como parâmetros valores idênticos a definição da tabela.

Exemplo: Em um arquivo com a seguinte estrutura:

CAMPO1 – Caracter de 10 posições. CAMPO2 – Numérico de 14 Posições com 2 decimais.

Para se criar um índice que ordene o arquivo por CAMPO1 + CAMPO2 deverá o seguinte comando ser utilizado:

INDEX ON CAMPO1+STR(CAMPO2,14,2) TO ARQIND

No caso do SigaAdvanced você deve colocar o índice na tabela SINDEX.

2.7.3. Índices condicionais

Nos gerenciadores de banco de dados não existe a figura dos índices condicionais. Para se obter resultados semelhantes aos índices condicionais o TOPConnect agregou nova funcionalidade ao filtro do SigaAdvanced / AP5.

Considere uma aplicação que crie o seguinte índice:

INDEX ON CODIGO,NOME FOR ESTADO = "SP" AND SALDO > 10000

Com o TOPConnect este índice seria o mesmo que:

SET FILTER TO ESTADO = "SP" .AND. SALDO > 10000 .AND. ORDERBY(CODIGO,NOME)

dbSetOrder(0)

O TOPConnect permite o uso da função OrderBy nos filtros o que reproduz o mesmo efeito de um índice filtrado.

O TOPConnect disponibiliza os dados na ordem solicitada pela cláusula OrderBy na Ordem 0 do arquivo, não interferindo assim com os índices do arquivo.


2.7.4. Chaves numéricas compostas

Os SGDB's não suportam índices que contenham expressões ADVPL onde dois campos numéricos são somados na chave.

Exemplo: INDEX ON CPOVAL1 + CPOVAL2 TO ARQIND

2.7.5. Expressões de filtro com funções e variáveis

Uma vez que o TOPConnect utiliza a arquitetura Cliente/Servidor o servidor não tem como avaliar o conteúdo de uma variável de memória ou o retorno de uma função do cliente.

O TOPConnect permite a utilização de variáveis e funções nos filtros porém é necessário ter em mente que a avaliação deste filtro ocorrerá no cliente e não no servidor o que poderá resultar em problemas de performance.

Analisando o seguinte filtro : SET FILTER TO CODIGO > "01000" .AND. CODIGO < "02000"

Este filtro contem apenas campos e constantes o que permite que sua avaliação seja feita no servidor e que apenas os registros que obedeçam ao filtro venha para o cliente.

Agora este: SET FILTER TO CODIGO > RetornaCodigo()

Considerando que RetornaCodigo é uma função ADVPL da aplicação todas as linhas deste arquivo serão avaliadas no cliente.

Visando minimizar os problemas de performance o TOPConnect conta com um sistema chamado SFE (Smart Filter Engine) o que faz com que o máximo possível de uma expressão seja avaliada no servidor.

Pôr exemplo: SET FILTER TO ESTADO = 'SP' .AND. SALDO > 10000 .AND. CODIGO > RetornaCodigo() Nesta expressão somente virão para o cliente os registros onde os campos ESTADO e SALDO obedeçam ao filtro e então o campo CODIGO será avaliado no cliente.


2.8. Comandos

Neste capítulo mencionaremos apenas os comandos da linguagem ADVPL que tem a sua funcionalidade alterada ou complementada e os novos comandos implementados pelo TOPConnect via RDD.

Para a utilização destes comandos o programa deverá conter a seguinte instrução:

#INCLUDE "TOPCONN.CH"

2.8.1. APPEND FROM

Em uma aplicação ADVPL o comando APPEND FROM é utilizado para se inserir registros na Work Area corrente com registros vindos de outro arquivo DBF. No TOPConnect o comando APPEND FROM importara registros de um arquivo DBF para uma tabela do banco de dados.

No ADVPL opcionalmente poderá ser especificado o parâmetro VIA "TOPCONN" o que fará com que registros de uma tabela sejam inseridos na Work Area corrente.

Exemplo SELECT CLIENTES //Importa registros de um DBF APPEND FROM c:\temp\newcli.dbf Ou SELECT CLIENTES //Importa registros da tabela NEWCLI APPEND FROM NEWCLI VIA "TOPCONN"

2.8.2. COPY TO

Em uma aplicação ADVPL o comando COPY TO é utilizado para se copiar a estrutura e os registros da Work Area corrente para um arquivo DBF.

No TOPConnect o comando COPY TO é utilizado para exportar a estrutura e os registros de uma tabela do banco de dados para um arquivo DBF.

Assim como no comando APPEND FROM no ADVPL o parâmetro opcional VIA também pode ser especificado.


2.8.3. USE

Abre uma tabela no banco de dados. Sintaxe:

USE [<xcTable>

[INDEX <xcIndex list>] [ALIAS <xcAlias>] [EXCLUSIVE | SHARED] [NEW] [READONLY] VIA "TOPCONN"

<cTable> O nome da tabela a ser aberta. INDEX <cIndex List> Especifica o nome de 1 a 15 índices a serem abertos na Work Area corrente. ALIAS < cAlias> Especifica um nome para a Work Area onde a tabela será aberta EXCLUSIVE Especifica que apenas este usuário terá acesso a esta tabela. Todas as outras tentativas de colocar esta mesma tabela em uso falharão. SHARED Especifica que a tabela será aberta em modo compartilhado. NEW Abre a tabela <cTable> na próxima Work Area disponível. Se esta clausula não for especificada, <xcTable> será na Work Area corrente. READONLY Abre <cTable> apenas para leitura. VIA "TOPCONN" Este parâmetro indica ao ADVPL que esta Work Area será gerenciada pelo TOPconnect. Se nenhum parâmetro for especificado a tabela aberta na Work Area corrente será fechada.

Exemplo //Abre a tabela de Clientes em uma nova Work Area USE clientes SHARED NEW VIA "TOPCONN"

2.8.4. BEGIN, COMMIT, ROLLBACK TRANSACTION

Marca o início de uma transação no banco de dados. Desde o ponto em que uma aplicação executa um BEGIN TRANSACTION cada APPEND ou REPLACE encontrado até um COMMIT TRANSACTION ou ROLLBACK TRANSACTION serão considerados uma única transação. Os demais usuários somente terão acesso aos novos registros ou às modificações após um COMMIT TRANSACTION Exemplo #INCLUDE "TOPCONN.CH" SELECT CLIENTES if !Rlock() Alert("Registro em uso!") Return .f. Endif BEGIN TRANSACTION

//Atualiza saldo no cadastro de clientes

REPLACE SALDO WITH SALDO – nValor

//Adiciona um pedido


SELECT PEDIDOS APPEND BLANK

REPLACE NUM WITH cNumero REPLACE VALOR WITH nValor

SELECT ITEMS

APPEND BLANK

REPLACE NUM WITH cNumero REPLACE QUANT WITH nQuant

.....

APPEND BLANK

REPLACE NUM WITH cNumero REPLACE QUANT WITH nQuant

.....

COMMIT TRANSACTION


2.9. Funções

2.9.1. TCCANOPEN

Verifica a existência de tabelas e índices no servidor. Sintaxe

TCCanOpen(cTable [, cIndice]) =>lógico

Exemplo //Testa a existência da tabela customer IF !TCCanOpen("CUSTOMER") dbCreate("CUSTOMER", aStru, "TOPCONN") ENDIF USE CUSTOMER SHARED NEW VIA "TOPCONN" //Testa a existência do índice IF !TCCanOpen("CUSTOMER","CUSTCOD") INDEX ON CODIGO TO CUSTCOD ELSE SET INDEX TO CUSTCOD ENDIF ...

2.9.2. TCCONTYPE

Especifica o protocolo de comunicação a ser utilizado pelo TOPConnect. Sintaxe

TCConType(<cType>)

Onde <cType> pode ser:

TCPIP Utiliza o protocolo TCP/IP. NPIPE Utiliza o protocolo Named Pipes. APPC Utiliza o protocolo APPC. BRIDGE Utiliza o utilitário TOPBrigde para comunicação de estações DOS NPIPE com servidor AS/400 utilizando TCP/IP. Exemplo #INCLUDE "TOPCONN.CH" //Especifica conexão TCP/IP TCConType("TCPIP") //Conecta-se ao ambiente SIGAADV no Microsoft SQL-Server TCLink("MSSQL/SIGAADV")

2.9.3. TCDELFILE

Exclui uma tabela no servidor. Sintaxe

TCDelFile(<cTable>)

Onde <cTable> é o nome da tabela a ser excluída. Exemplo TCDelFile("CUSTOMER")


2.9.4. TCGETDB

Retorna o Tipo de Banco de Dados corrente

cDataBase := TCGETDB()

Onde os valores de retorno são :

MSSQL Microsoft SQL-Server 6.5 MSSQL7 Microsoft SQL-Server 7.0 ORACLE Oracle DB2 IBM Universal Database SYBASE Sybase SQL-Server ANYWHERE Sybase SQL Anywhere ANYSYBASE Sybase SQL Anywhere

(Emulando Sybase SQL-Server) INFORMIX Informix

2.9.5. TCLINK

Abre uma conexão com o Servidor TOPConnect. Sintaxe

nCon := TCLink(<cConectString>,<cServer>)

Onde o parâmetro <cConnectString> é composto por:

Para TOPConnect NT : Nome do Banco de Dados / Nome do Ambiente Para TOPConnect/400: Nome do Ambiente

O parâmetro <cServer> contém: Para conexões NamedPipe, APPC e Brigde : O nome do servidor TOPConnect Para conexões TCP/IP : O endereço IP do servidor TOPConnect Para o TOPConnect NT acessando Oracle, um ambiente é o nome do Alias criado com o utilitário SQL-Net.

Para o TOPConnect NT acessando os demais SGDB's um ambiente é um System DSN criado através do ODBC Data Source Administrator.

Para o TOPConnect AS/400 um ambiente é uma Library criada através do comando CRTTOPENV do TOPConnect.

Para informações sobre a criação de ambientes consulte o manual de instalação do TOPConnect.

Esta é a lista de Bancos de Dados hoje suportados e seus respectivos nomes compor a string de conexão com o TOPConnect NT:

Microsoft SQL-Server 6.5 MSSQL Microsoft SQL-Server 7.0 MSSQL7 Oracle ORACLE IBM Universal Database DB2 Sybase SQL-Server SYBASE Sybase SQL Anywhere ANYWHERE Sybase SQL Anywhere


(Emulando Sybase SQL-Server) ANYSYBASE Informix INFORMIX

A função TCLink retorna ou o número da conexão ou um valor negativo contendo o código do erro.

Exemplo

//Conecta-se ao Microsoft SQL-Server no ambiente SIGAADV //Protocolo Named Pipes TCConType("NPIPE")

nCon := TCLink("MSSQL/SIGAADV","TOPSRV") if nCon < 0 //Conexões com retorno < 0 significam erro Alert("Falha de conexão com o TOPConnect") endif //Protocolo TCP/IP TCConType("TCPIP") //Conecta-se ao Oracle – no ambiente TESTES nCon := TCLink("ORACLE/TESTES",172.16.1.2)

//Protocolo APPC //Conecta-se ao AS/400 no ambiente PRODUCAO nCon := TCLink("PRODUCAO","TOP400")


2.9.6. TCQUERY

Executa uma Query no servidor e coloca seu retorno em uma WorkArea. Sintaxe:

TCQUERY [<cSQLExpr>

[ALIAS <xcAlias>] [NEW] VIA "TOPCONN"

<cSQLExpr> Expressão SQL a ser enviada ao servidor. ALIAS < cAlias> Especifica um nome para a Work Area a ser aberta NEW Abre a tabela <cTable> na próxima Work Area disponível. Se esta clausula não for especificada, <xcTable> será na Work Area corrente. VIA "TOPCONN" Este parâmetro indica ao ADVPL que esta Work Area será gerenciada pelo TOPconnect. A Work Area criada com o comando TCQUERY é READ-ONLY, portanto não é permitido o uso de APPEND's ou REPLACE's. O TOPConnect tem apenas um cursor para a Query executada portando apenas os seguintes comandos são suportados em uma Work Area criada com TCQUERY: GO TOP - DbGoTop() GO BOTTOM - DbGoBottom() SKIP - DbSkip() Eof() Bof()

Obs: Ao executar uma Query que retorne um ou mais valores calculados, o nome dos campos da WorkArea serão COLUMN1, COLUMN2... COLUMNn. Exemplo

//Abre a tabela de Clientes em uma nova Work Area cQuery := "SELECT a.codigo, b.nome FROM CLIENTES a, CLIDATA b ; WHERE a.CODIGO = b.CODIGO ORDER BY CODIGO,NOME" TCQUERY cQuery ALIAS CLIENTES NEW VIA "TOPCONN" dbGoTop() While !Eof() ? CODIGO,NOME dbSkip() end USE cQuery := 'SELECT SUM(VALOR),SUM(SALDO) FROM CUSTOMER' TCQUERY cQuery NEW VIA "TOPCONN" ?COLUMN1 //Somatoria dos valores ?COLUMN2 //Somatoria dos saldos


2.9.7. TCQUIT

Encerra todas as conexões com o TOPConnect Sintaxe TCQuit()

2.9.8. TCSETCONN

Seleciona conexão ativa.

Sintaxe TCSETCONN(<nConn>) Onde <nConn> é o número da conexão. Exemplo // Abre conexão com o ambiente de Produção nCon1 := TCLink("MSSQL/PRODUCAO") if nCon1 < 0 Alert("Falha conectando ambiente de Produção") QUIT endif

// Abre conexão com o ambiente de Testes nCon2 := TCLink("MSSQL/TESTES")

if nCon2 < 0 then Alert("falha conectando ambiente de Testes") QUIT endif

TCSetConn(nCon1)

//Abre tabela de Clientes no ambiente de produção USE CUSTOMER ALIAS PROD SHARED NEW VIA "TOPCONN"

TCSetConn(nCon2)

//Abre tabela de Clientes no ambiente de testes USE CUSTOMER ALIAS TEST SHARED NEW VIA "TOPCONN" ...

2.9.9. TCSETFIELD

Esta função serve como apoio ao comando TCQUERY, na recuperação de campos tipo NUMERIC, DATE e LOGICAL, pois os mesmos são gravados fisicamente no Banco de Dados como caracteres, e no caso dos numéricos como float.

Sintaxe TCSetField(<cAlias>, <cField> ,<cType>, [<Prec.Inteira>,<Prec.Decimal>] )

Onde <cAlias> é o alias da WorkArea, <cField> é o nome do campo e <cType> é o tipo desejado para o campo.

Exemplo


TCQUERY "SELECT NOME, DATA, MARRIED, VALOR FROM CUSTOMER" ALIAS QUERY VIA "TOPCONN"

TCSetField("QUERY","DATA","D") TCSetField("QUERY","VALOR","N",12,2)

Dentro de um programa ADVPL já podemos considerar como um campo data não mais um campo caracter como é o seu armazenamento.

O campo Data só é retornado como um campo caracter por que estamos utilizando a função TCQUERY, se não o tratamento é automático.

2.9.10. TCSPEXEC

Executa uma Stored Procedure no Banco de Dados.

Devido a uma limitação em alguns dos Bancos de Dados suportados na obtenção dos tipos de parâmetros (se são de INPUT e/ou OUTPUT) todos as Stored Procedures a serem executadas através do TOPConnect deverão obedecer o seguinte padrão de nomenclatura de seus parâmetros :

Parâmetros de INPUT devem começar com IN_... Ex. IN_VALOR. Parâmetros de OUTPUT devem começar com OUT_... Ex. OUT_CODIGO

Após a execução de uma Stored Procedure o TOPConnect retornará ao ADVPL um array com 'n' elementos, onde n é o número de parâmetros de OUTPUT da Stored Procedure.

Sintaxe <aRet> := TCSPExec(<cSPName>,[<xParam1>,<xParam2>...<xParamN>])

Onde <aRet> é um array com os parâmetros de retorno da Stored Procedure e <cSPName> é o nome da Stored Procedure a ser executada e os demais parâmetros variam conforme a definição da Stored Procedure.

Exemplo //Verifica se a Stored Procedure Teste existe no Servidor If TCSPExist("TESTE") //Executa a Stored Procedure Teste aRet := TCSPExec("TESTE","JOSE",1000) if aRet <> nil

For i:= 1 to Len(aRet) //Mostra os valores de retorno ?aRet[i] Next Else ?"Erro executando Stored Procedure" ?"Mensagem: "+TCSQLError() Endif EndIf


2.9.11. TCSPEXIST

Verifica a existência de uma determinada Stored Procedure no servidor. Sintaxe <lExist> := TCSPExist(<cSPName>)

Onde <lExist> indica se a Stored Procedure existe ou não e <cSPName> é o nome da Stored Procedure procurada.

Exemplo If SPExist("CALCCUSTO") TCSPExec("CALCCUSTO") Endif

2.9.12. TCSQLERROR

Retorna o último erro registrado pelo TOPConnect durante a execução de uma Query.

Sintaxe <cError> := TCSQLError()

Onde <cError> é a mensagem de erro. Exemplo If TCSQLExec("UPDATE CUSTOMER SET VALUE=0") < 0 then ?TCSQLError() Endif

OBS: Esta é a mesma mensagem que esta registrada no log de eventos do TopConnect Manager.

2.9.13. TCSQLEXEC

Executa comandos SQL no servidor. Sintaxe

<nRet> := TCSQLExec(<cCommand>)

Onde <nRet> retorna um valor negativo em caso de erros e <cCommand> e o comando SQL a ser executado. Exemplo TCSQLExec("UPDATE CUSTOMER SET VALUE=0)


2.9.14. TCSRVTYPE

Retorna o Tipo do Servidor onde esta sendo executado o TOPConnect. Sintaxe

<cType> := TCSrvType()

Onde <cType> é o tipo do servidor podendo Ter seu conteúdo igual a "WinNT" ou "AS/400". Exemplo TCLink("MSSQL/TESTE","TOPSRV") ?TCSrvtype()

2.9.15. TCUNLINK

Encerra uma conexão com o TOPConnect. Sintaxe

TCUnlink(<nConn>)

Onde <nConn> é o número da conexão retornado pela função TCLink() Exemplo TCConType("NPIPE") nConn := TCLink("MSSQL/TOPCONN","TOPSRV") TCUnLink(nConn)

2.9.16. TCCHKOBJ*

Verifica a existência de um objeto no servidor AS/400 Sintaxe

<nError> := TCChkObj(<cObj>,<cLibrary>,<cType>)

Onde: <nError> é 0 quando o objeto existe ou o número do erro no AS/400. <cLibrary> é o nome da biblioteca que deve conter o objeto. <cType> é o tipo de objeto AS/400. Ex: *FILE, *PGM, etc. Exemplo nError := TCChkObj("CALCCUST","PRODUCAO","*PGM") ESTA FUNÇÃO SE APLICA APENAS PARA O TOPCONNECT AS/400



2.9.17. TCEXEERROR*

Retorna uma string com a mensagem de erro retornada pela execução das funções TCPGMEXE() e TCSYSEXE(). Sintaxe <cError> := TCExeError()

Onde <cError> é a string com a mensagem de erro. Exemplo ?TCExeError()


2.9.18. TCPGMEXE*

Executa um programa no servidor AS/400

TCPGMEXE( program name )


2.9.19. TCSYSEXE*

cCommand := "CRTCBLMOD MODULE("+cTDataBase+"/"+ cName+"F"+cCrrEmp+") " cCommand += "SRCFILE("+cTDataBase+"/QSPSRC) " cCommand += "SRCMBR("+cName+"F"+cCrrEmp+") "

cCommand += "REPLACE(*YES)"

TCSysExe( cCommand )



2.10. Performance

2.10.1. Otimizando seu código

A linguagem ADVPL tem um enfoque posicional, recuperando os dados utilizando orientação a registros, enquanto aos Bancos de Dados SQL recuperam os dados por blocos de dados. Devido a esta diferença conceitual, vários pontos devem ser levados em consideração para que se possa obter uma boa performance e utilizar os recursos de uma aplicação Client/Server.

2.10.2. Leitura Sequencial

Operações de leitura seqüencial de uma tabela podem levar a problemas de performance. Vamos analisar o seguinte código: dbSelectArea("CLIENTES") nValor := 0 Do While !Eof() If ESTADO = "SP" nValor += SALDO Endif DbSkip() End

O código acima fará com que todas as linhas(registros) da tabela venham para o Client, o que irá gerar um número de Queries no servidor igual ao número de linhas da tabela e cada uma delas irá recuperar apenas uma linha, subtilizando a capacidade de processamento do servidor.

O código acima poderia ser substituído por: TCQUERY "SELECT SUM(SALDO) ; FROM CLIENTES ; WHERE ESTADO = 'SP'" NEW nValor := COLUMN1 Com a utilização do comando TCQUERY todo a somatória é feita no servidor retornando assim para a aplicação apenas uma linha com o resultado desejado.


2.10.3. O uso de filtros

O uso de filtros em aplicações ADVPL são conhecidos como fonte de problemas de performance. Isto se deve ao fato de que todos os registros são avaliados pela estação.

O mesmo não ocorre utilizando o TOPConnect, pois o filtro é avaliado pelo próprio servidor vindo para a estação apenas os registros que respeitem a condição do filtro.

Para que um filtro tenha uma boa performance é necessário que a expressão do filtro corresponda a um índice no servidor, caso contrário, para poder avaliar o filtro o servidor SQL terá que ler linha a linha da tabela.

2.10.4. Stored Procedures

O uso de Stored Procedures é a maneira mais eficiente de uma aplicação se utilizar dos benefícios da arquitetura Cliente/Servidor.

O TOPConnect suporta o uso de Stored Procedures conforme documentado na função TCSPExec()


2.11. Integração com outros aplicativos

2.11.1. Incluindo registros nas tabelas do SigaAdvanced / AP5

As tabelas criadas no Banco de dados pode receber inserções de outros aplicativos, esta inserção deve ser feita contemplando as seguintes operações :

Antes de inserir o registro você deve obter o número máximo da coluna R_E_C_N_O_ existente na tabela Deste número você deve somar 1 Logo em seguida fazer a inserção propriamente dita do registro Se o registro não for inserido com sucesso você deve voltar ao primeiro passo.

Alerta!: Em alguns Bancos de Dados o Topconnect estará registrando no log de eventos do Topconnect Manager, um mensagem de alerta dizendo que existe duplicidade de registro. (Desconsiderar esta mensagem, de tempos em tempos você deve limpar o Log do TopConnect.

2.11.2. Excluindo registros ( Sempre Marcar )

Quando houver necessidade de exclusão de registro por outros aplicativos você deve apenas fazer uma operação de alteração do registro, colocando o símbolo de ‘*’ na coluna D_E_L_E_T_, principalmente se esta operação for concorrente com o SigaAdvanced / AP5.

2.11.3. Vantagens e Desvantagens

As vantagens deste processo é a agilidade na integração entre os sistemas, não existe a necessidade de gerar arquivos textos, para depois fazermos a integração. Principalmente em situações on-line , utilizar o recurso do Banco é uma das melhores saídas.

As desvantagens deste processo, são que você deve estar ciente de todas atualizações que são feitas na base de dados no sistema, já que o sistema esta desta forma vulnerável a problemas inesperados.

Normalmente aconselhamos a sempre fazer a atualização em tabelas específicas e depois criar rotinas pelo sistema o qual repassarão os dados destas tabelas para as tabelas definitivas, desta forma vamos evitar problemas na atualização de versão, ou até em alguma mudança de estrutura que o configurador faça.(Você estará perdendo os triggers desta tabela).


3. Ferramenta importante

3.1. Instalador de Stored Procedures no Banco de Dados

Alguns clientes utilizam rotinas como Stored Procedures para agilizar alguns processos críticos do sistema, para instalação destas Storeds Procedures você devem possuir o arquivo com o nome de SIGAXXX.SPS, onde o XXX é o tipo de Banco de Dados que o Cliente estará utilizando ex: SIGASQ7 (MSSQL 7.0), SIGAIFX (INFORMIX), SIGAORA (ORACLE)

Após a confirmação desta operação todas as Procedures que estiverem disponíveis neste arquivo serão compiladas para a empresa em questão, se o cliente tiver mais do que uma empresa e ele deseja instalar as procedures em todas as empresas ele precisa entrar em cada empresa.

Se houver qualquer problema na instalação das Stores Procedures será gerado um arquivo de log chamado SPBuild.LOG no diretório \SIGAADV\. E também será apresentado o erro no Log do TopConnect.

microsiga - programacao sql inter media rio

Documents

dados que

e sql server

dados tabela

dados oracle

dados informix

dados sybase

dados relacionais

dados passa