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).

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.

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
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 QUANT WITH nQuant
.....
APPEND BLANK

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
//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

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Microsiga - Programacao SQL Inter Media Rio

Încărcat de

Drepturi de autor:

Formate disponibile

Programação SQL com SIGA Advanced / AP5

Programação SQL (Intermediário)

Com SigaAdvanced/ AP5

1. Introdução ao ambiente Relacional

1.2. Conceitos Básicos de Banco de Dados

Um banco de dados não trabalha em função de registros, ou Arquivos como nós

Os índices trabalham de forma semelhante ao DBF, e são utilizados com duas

Também estarão ligados à uma tabela específica os Triggers, e as Foreign Keys (

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

Devido ao controle exercido sobre os dados a performance do banco acaba sendo

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 é

Para definição de transação pelo usuário, normalmente se utilizam os

A área de LOG do Banco de dados é normalmente definida com 25% do

1.3.1.2. Segurança e Backup

O LOG também é utilizado para fazer o backup de grande bancos de dados,

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

Conhecendo melhor o processo de gravação do banco de dados, percebemos

1.3.2. Área temporária do Banco de Dados

Esta área é de utilidade exclusiva do Banco de Dados, a mesma é utilizada em

1.4. Normalização de Base de Dados

A normalização de Base de dados tem como objetivo, definir a estrutura de entidades e

Ex.: Entidade = Pedido

Ex.: Entidade = Pedido

Entidade = Itens do Pedido

Ex.: Entidade = Pedido

1.5. MER (Modelo Entidade Relacionamento)

A partir da normalização podemos definir as relações estrangeiras de cada tabela, o MER

Sempre que possível ao desenvolver processos específicos no sistema procure desenhar

1.6. Diferenças cruciais entre ambientes DBF e SQL

Quando trabalhamos em um ambiente posicional, vários regras de programação e

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

Agora quando trabalhamos com Base de Dados Relacional, a estrutura é totalmente

2.1. Informações gerais

O TOPConnect foi desenvolvido em linguagem ‘C’ pela Microsiga e é utilizado hoje

MS-SQL Server 6.5 e 7.0 ( MSSQL / MSSQL7 )

O TOPConnect é composto por um biblioteca replaceble database driver(RDD) e

2.2. Controle de tipo de dados ( Tabela TOP_FIELD )

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

Os campo caracter não recebem nenhum tratamento.

A tabela TOP_FIELD contem a descrição de todos os campos NAO-CARACTER, para

Ex.: Tabela SA1010

FIELD_TABLE FIELD_NAME FIELD_TYPE FIELD_PREC FIELD_DEC

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

A parte mais importante do Topconnect Manager é o gerenciamento das mensagens de

2.4. Sistema de controle de Registros

Acreditamos que muitos já perguntarão por que da existência da coluna

Alerta! : Se você possui programas específicos desenvolvidos (RDMAKES), você

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

2.4.2.1. Limite de registros

O limite de registros em uma tabela é de 2,147,483,648 , este número

2.4.2.2. Renumeração da coluna RECNO

Quando os registros são deletados pelo sistema, os mesmos são apenas

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

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

Neste momento a tabela TOP_FIELD estará sendo alimentada com todos os

Alerta! : Após o primeiro usuário fazer a conexão com o TopConnect e a parte de