Apostilaguiabasedados

GUIA DA BASE DE DADOS
Reviso 7

Suporte Tcnico:
Newsgroup: news://dataaccess.com/dac-public-newsgroups.visual-dataflex-support
Web Site (URL): http://www.dataaccess.com.br
Site FTP: ftp.dataaccess.com

Part Number: 006900.DG

OBSERVAO SOBRE DIREITOS AUTORAIS
Copyright 2001, Data Access do Brasil. Todos os direitos reservados.
Nenhuma parte desta publicao pode ser copiada ou distribuda, transmitida,
transcrita, arquivada para posterior recuperao, traduzida para qualquer
forma de linguagem humana ou computacional, de qualquer forma ou meio,
seja eletrnico, mecnico, magntico, manual, ou qualquer outro, ou ainda
repassada a terceiros sem a expressa permisso por escrito da Data Access
do Brasil.
LIMITES DE RESPONSABILIDADE
A Data Access do Brasil no fornece nenhuma garantia, expressa ou implcita,
sobre a adequao deste produto ou sua documentao para uma aplicao
especfica.
A Data Access do Brasil se reserva o direito de rever o contedo desta
documentao, efetuando alteraes, sem a obrigao de notificar pessoas,
instituies ou organizaes.
A autorizao de distribuio deste produto pertence Data Access do Brasil,
e foi fornecida pela Data Access Corporation.
Este produto est adequado, protegido e registrado de acordo com a lei de
Software N.7646/87
MARCAS REGISTRADAS
DataFlex marca registrada da Data Access Corporation.
Pervasive.SQL marca registrada da Pervasive Software, Inc.
Windows Microsoft Corporation.
Todos os outros nomes de produtos referidos nesta documentao so marcas ou
marcas registradas e pertencem aos seus respectivos proprietrios.

3
ndice
USANDO OBJETOS DICIONRIO DE DADOS...................................... 9
O que os DDOs Fazem............................................................... 9
A Classe DataDictionary.......................................................... 10
Como os Dicionrios de Dados Funcionam.................................. 10
Configurando as Propriedades na Define_Fields.......................... 11
Configurando as Propriedades do Arquivo................................... 11
Campos Chave................................................................................ 20
Opes de Validao do Campo.................................................... 21
Configurando Padres ................................................................... 28
Definindo os Padres do Campo................................................... 28
Construindo Subclasses Data-Dictionary ..................................... 29
As Mensagens de Operao do Dicionrio de Dados................... 31
Desfazendo uma Transao........................................................... 35
Erros nos Dicionrios de Dados.................................................... 36
Travamento Inteligente do Arquivo................................................ 36
Utilizando as Mensagens Gancho .............................................. 37
As Mensagens Gancho de Validao ............................................ 39
Procedures Update, Backout ......................................................... 43
Criando as Procedures / Funes Validate, Entry, & Exit ..... 47
Utilizando Tabelas de Validao.................................................... 48
Criando um Objeto ValidationTable............................................... 49
Tabelas de Validao Globais vs. Dedicadas................................ 56
O Buffer Local do Campo ........................................................ 60
A Propriedade Current_record................................................ 61
As Mensagens de Procura....................................................... 62
Request Assign............................................................................... 62
Como os Objetos de Entrada de Dados Interagem com os
Dicionrios de Dados............................................................... 63
Construindo Estruturas de Dicionrio de Dados................... 65
Propagao das Operaes do Dicionrio de Dados ................... 68

4
Estrutura de Arquivo em forma de Diamante................................ 75
Conectando mais que Um DDO ao Mesmo Arquivo ..................... 77
Utilizando os Arquivos de Sistema nos Dicionrios de Dados .... 78
Constraints............................................................................... 80
O Comando Constrain.................................................................... 80
Programando Restries nos DDOs.............................................. 81
Restries Variveis....................................................................... 82
Otimizao da Procura com Restrio .......................................... 83
Tpicos Avanados do Dicionrio de Dados......................... 83
Controlando as Excluses em Cascata .............................. 83
Travamento Inteligente do Arquivo de Dados........................ 85
Utilizao Bsica do Smart-Filemode............................................ 85
Tratando Arquivos fora da Estrutura............................................. 86
Como o Smart Filemode Funciona ................................................ 88
Smart Filemode e Arquivos Fantasmas......................................... 89
Mecanismo de Atualizao...................................................... 90
O Comando Is_file_included.......................................................... 91
Os Inteiros de Operao do Dicionrio de Dados.................. 92
Auto-preenchimento e Dicionrios de Dados ........................ 94
Gravando e Excluindo.................................................................... 95
Validao e Constraints ................................................................. 95
Validao do Item........................................................................... 95
Validao durante a Navegao do Item ....................................... 96
Controlando as Conexes do DDO......................................... 98
Conectando os DDOs aos DDOs.................................................... 98
Conectando os DEOs aos DDOs.................................................... 99
Cdigo de Exemplo do Dicionrio de Dados ....................... 101
Customer.dd ..................................................................................101
Vendor.dd.......................................................................................107
Salesp.dd .......................................................................................111
Invt.dd ............................................................................................114
OrderHea.dd...................................................................................118

5
Orderdtl.dd.....................................................................................124
GERENCIADOR DE BANCO DE DADOS DATAFLEX.........................129
Os Arquivos de Banco de Dados do DataFlex..................... 129
Estrutura Lgica de um Arquivo do Banco de Dados..................129
Registros........................................................................................135
Arquivos do Diretrio da Base de Dados............................. 136
O Filelist.................................................................................. 138
Mtodos para o Acessar os Arquivos do Banco de Dados .........139
As Ferramentas do Banco de Dados .................................... 140
O Database Builder........................................................................140
Desenvolvendo e Mantendo os ndices................................ 142
ndices Batch vs Online.................................................................142
Segmentos Case-Insensitive e Descendentes .............................143
Suportando Selees ....................................................................144
Relacionamentos de Arquivos .............................................. 144
Mecanismos dos Relacionamentos..............................................145
Utilizando Relacionamentos de Arquivo ......................................146
Utilizando o Banco de Dados nos Programas ..................... 149
Grupo de Comandos do Banco de Dados....................................149
Abrindo os Arquivos do Banco de Dados....................................151
Procurando Registros ...................................................................152
Criando e Alterando Registros......................................................158
Consideraes sobre Multi-Usurios ................................... 159
Sempre Executar Edies em um Estado de Travamento .. 162
Grupo de Comandos Multi-Usurio ..............................................163
Processamento da Transao............................................... 164
O que o Processamento da Transao......................................164
Tipos de Processamento de Transao .......................................169
Como o Processamento Client-Atomic de Transao Funciona.170
Processamento Server-Atomic de Transao..............................171
Grupo de Comandos do Servidor .................................................172

6
Comandos que no devem ser Executados em uma Transao.172
Erros em Transaes ....................................................................173
Concluso......................................................................................174
Gerenciando os Arquivos do Banco de Dados em Tempo de
Execuo ................................................................................ 175
Conservando Memria e Manipulaes de Arquivos...................175
Utilizando o Mesmo Arquivo em Mais de Um Programa..............176
Acessando Filelists .......................................................................177
Criando e Modificando a Estrutura do Arquivo............................177
Atributo ..........................................................................................181
Valor padro...................................................................................181
Grupo de Comandos de Estrutura................................................185
Abrindo Arquivos que no foram Declarados na File List...........186
O Driver DataFlex de Banco de Dados ................................. 186
Funes..........................................................................................186
Funes de Callback.............................................................. 188
APNDICE A NOMES DE ARQUIVOS & TIPOS DE EXTENSO.....191
Atributos do DataFlex............................................................ 193
Diferenas da API ..........................................................................193
APNDICE B ESPECIFICAES DO VISUAL DATAFLEX .............194
Caractersticas...............................................................................194
Requisitos............................................................................... 194
Plataformas............................................................................. 195
Estrutura................................................................................. 195
Connectivity Kits.................................................................... 195
Especificaes da Base de Dados (Todas as Bases de Dados
usadas com VDF) ................................................................... 195
Registros em arquivos DataFlex & Especificaes dos Arquivos
................................................................................................. 195
Especificaes de ndices para a base DataFlex................. 196

7
Especificaes de Campos para a base DataFlex ............... 197
Aplicao / Cdigo................................................................. 197
Arquivo de Programa Visual DataFlex.................................. 198
Tamanho do Argumento........................................................ 199
Guia da Banco de Dados Visual DataFlex

9
1
U
s
a
n
d
o

D
D
O
s

Usando Objetos Dicionrio de Dados
Este captulo abrange a parte interna dos objetos de dicionrio de dados (DDOs) na
manipulao da base de dados do disco.
O que os DDOs Fazem
Os DDOs servem para dois propsitos: eles coordenam a atividade da base de dados
entre os objetos de entrada de dados (DEOs), e fornecem servios de validao e
atualizao da base de dados para um programa. Estes dois propsitos so distintos. A
criao de uma estrutura de DDOs, conectando os objetos apropriadamente (com set
ddo_server e restries) e conectando os DEOs apropriadamente a essa estrutura (com
set server) fornece uma atividade coordenada da base de dados. Voc programa tudo
isso no nvel do objeto. As regras do banco de dados so mantidas e foradas atravs
da criao de vrias procedures e funes gancho no dicionrio de dados dentro das
classes data-dictionary. Voc programa isso no nvel da classe. O trabalho com os
DDOs consiste de:
1. Criao de uma subclasse data-dictionary para cada arquivo de dados,
nomeando o arquivo de dados como o main_file, e codificando as regras do
banco de dados nessas propriedades, funes e procedures das classes (por
exemplo, define_fields, update, backout, creating, validate_save,
validate_delete).
2. Criao de DDOs baseados nas classes criadas no Passo 1.
3. Posicionamento desses objetos dentro de views, conect-los a outros DDOs
atravs da mensagem set ddo_server e conectar os DEOs estrutura de DDOs
com a mensagem set server.
A mensagem set ddo_server conecta um DDO client a um DDO server (filho para pai).
Algumas vezes nos referimos a isto como link de atualizao. Um grupo de DDOs
conectado atravs de uma estrutura de atualizao.
A mensagem set server conecta um DEO a um DDO. Algumas vezes nos referimos a
isto como um link de uso. O DDO est utilizando os servios de seu servidor (o DDO).
Uma aplicao WebApp realmente no possui um objeto data-entry (entrada de dados)
individual (DEOs). O componente data-entry de uma Web Application seu web
browser. NO Visual DataFlex, a conexo entre o DDO e o DEO direta. Mudanas no
DEO so imediatamente refletidas no DDO e vice-versa.
No WebApp, a conexo entre seu DDO e DEO (seu browser) indireta, ou em lote.
Todas as mudanas em um DDO so enviadas para o browser em formato HTML como
Guia da Base de Dados Visual DataFlex

10
U
s
a
n
d
o

D
D
O
s

um simples evento. Todas as mudanas em um DEO (o browser) so enviadas para o
DDO como uma simples submisso em lote. Seu Objeto Web Business coordena esta
atividade.
Por isso, enquanto o mesmo DDO capaz de suportar diferentes interfaces com o
usurio (por exemplo, controle windows, pginas HTML, terminais de exibio de
caracteres), as habilidades dos DDOs para interface com interface visual sero
diferentes. A lgica bsica do DDO e servios de validao so suportados corretamente
atravs de todas as plataformas. Por exemplo, validaes de campos so sempre
executadas corretamente antes de uma gravao.
Algumas das funes do DDO no so suportadas atravs de todas as plataformas. Por
exemplo, as mensagens que so chamadas no momento da entrada e sada de um
campo no podem ser suportadas com um formulrio HTML. O DDO sempre ir fazer
tudo para auxili-lo. Por exemplo, se um campo est definido como capslock, ser
permitida a entrada de caracteres minsculos em entradas de formulrio HTML (no h
configurao para impedir isso). Contudo, antes que o valor seja movido para campo do
buffer do DDO ele ser corretamente convertido para maisculo.
A Classe DataDictionary
A classe DataDictionary permite que voc aplique um conjunto de regras a todos os
campos de um arquivo de dados sem ter que repetir estas regras em cada objeto de
entrada de dados (DEO) que acessa o arquivo. uma subclasse da classe DataSet e
deve ser utilizada para criar (pelo menos) uma subclasse para cada arquivo acessado
em uma aplicao. As regras que voc pode especificar no dicionrio de dados podem
alterar a estrutura do arquivo; especificar como ele se conecta com outros arquivos de
dados; quais propriedades e validaes do campo se aplicam, e quais interdependncias
existem entre os valores do campo em arquivos de dados diferentes.
Se voc est comeando a programar em DataFlex orientado a objetos, voc ver que
estes dicionrios de dados so ferramentas extremamente poderosas para padronizar
arquivos de dados e a maneira que eles so utilizados. Se voc j possui objetos da
classe DataSet em seus programas, voc pode alter-los e utilizar os dicionrios de
dados, ou pode utilizar uma combinao (desde que voc no misture os data sets e
dicionrios de dados na mesma view).
Como os Dicionrios de Dados Funcionam
As sees a seguir explicam como utilizar a classe DataDictionary e suas mensagens.
O item Class Reference da ajuda on-line do Visual DataFlex explica todas as mensagens
e suas sintaxes.

11
U
s
a
n
d
o

D
D
O
s

Definindo as Regras do Banco de Dados
As regras para um arquivo de dados so definidas em seu dicionrio de dados seguindo
os passos abaixo, normalmente na definio da subclasse. A maioria dos passos podem
ser feitos utilizando o Database Builder, o qual gera o cdigo para eles.
1. Definir todas as propriedades desejadas para o arquivo de dados. Essas
propriedades definem como todo o arquivo de dados deve se comportar. Essas
propriedades incluem a identificao do arquivo de dados principal e de todos os
arquivos pais e filhos necessrios atravs de seus filenumbers, e definem como
as gravaes e excluses sero processadas.
2. Definir todas as propriedades desejadas para o campo de dados. Essas
propriedades so especficas para cada campo de dados particular. Existem
vrias propriedades de campo, das quais a maioria especifica como um campo
deve ser formatado; como deve parecer-se; como as entradas para ele devem
ser validadas, e como a navegao do item dever ser manipulada pelo campo.
3. Criar qualquer processo de validao e tratamento de entrada e sada, se
necessrio. Se voc tiver atribudo mensagens para validao, sada, ou
entrada para qualquer campo, voc precisar definir as procedures e funes
que suportaro as mesmas. Se uma tabela de validao foi associada a um
campo, voc deve criar esse objeto de tabela de validao (algumas vezes ele
estar dentro do DDO, e outras vezes ser uma tabela de validao global que
poder ser compartilhada com outros dicionrios de dados).
4. Criar procedures e funes gancho. Durante as operaes de gravao e
excluso, mensagens gancho especiais so enviadas. Por padro, os
procedimentos no fazem nada. esperado que voc defina um processamento
personalizado nessas procedures e funes conforme o necessrio.
5. Elas so utilizadas primariamente para a verificao da validao e para a
manuteno dos valores de campo calculados.
Configurando as Propriedades na Define_Fields
Todas as propriedades do arquivo e do campo so configuradas pela procedure
define_fields. Provavelmente, essa procedure a procedure mais importante em um
dicionrio de dados.
Configurando as Propriedades do Arquivo
As propriedades mais comuns do arquivo so:

12
U
s
a
n
d
o

D
D
O
s

Main_File
Identifica o arquivo que a subclasse deve manipular. Voc deve configurar uma
main_file em seu dicionrio de dados. Em classes data-server mais antigas, essa
propriedade era configurada em uma procedure chamada construct_object. Apesar
disso ainda ser vlido, voc deve configurar a propriedade main_file dentro da
define_fields.
procedure define_fields
forward send define_fields
set main_file to customer.file_number
:
Add_Server_File / Add_Client_File
Voc adiciona arquivos lista de arquivos pais requeridos (required-parent-file) com a
mensagem add_server_file. A mensagem Add_client_file utilizada para adicionar um
arquivo lista arquivos filhos requeridos (required-child-file). Antes que uma gravao
ou excluso seja processada, o dicionrio de dados verificar os arquivos necessrios e
garantir que h um DDO para cada arquivo dentro da estrutura de dicionrio de dados,
e que eles esto conectados apropriadamente. Se no, a gravao ou excluso no
ocorrer. Isso assegura que a estrutura do dicionrio de dados est completa. Voc s
precisa declarar os arquivos pais e filhos imediatos no dicionrio de dados. Os arquivos
avs e netos sero vinculados atravs das declaraes dos dicionrios de dados dos
arquivos pai e filho.
set main_file to orderhea.file_number
send add_server_file customer.file_number
send add_server_file sales.file_number
send add_client_file orderdtl.file_number
:
Add_system_file
O comportamento padro de gravao ou excluso travar e reler todos os arquivos da
lista de arquivos abertos no momento da solicitao de gravao para o disco. Os
dicionrios de dados suportam uma caracterstica chamada smart filemode que pode
melhorar substancialmente a performance das gravaes e excluses. Isso controlado
pela propriedade smart_filemode_state. Quando todos os dicionrios de dados em uma

13
U
s
a
n
d
o

D
D
O
s

estrutura de dicionrios de dados possuem essa propriedade como true, apenas os
arquivos de dados que esto participando da operao sero travados e relidos. Se os
arquivos de sistema forem controlados com um link updating, eles so protegidos, se
no, para fazer que o smart filemode funcione apropriadamente com esses arquivo, ser
necessrio que voc declare-os com a mensagem add_system_file na procedure
define_fields. Em revises anteriores do DataFlex, isso era mais complicado e era
executado com a reset_filemodes_for_lock. A sintaxe da mensagem add_system_file
:
Send add_system_file f i l e [ l ock_t ype]
ARGUMENTO EXPLICAO
file O nome do arquivo de sistema
lock_type Condies de Save/delete para travar este arquivo.

Isso permite um travamento inteligente, no qual o arquivo s travado quando for
absolutamente necessrio (por exemplo, durante a gravao de um novo registro, mas
no durante a gravao de um registro existente). Os valores vlidos so:
DD_Lock_on_All, DD_Lock_on_Delete, DD_Lock_on_Save,
DD_Lock_on_New_Save, e DD_Lock_on_New_Save_Delete. Se no for fornecido
nenhum lock_type, lock_on_all utilizado.
Estes dois exemplos fazem a mesma coisa:
Send Add_system_file ordsys
Send Add_system_file ordsys dd_lock_on_all
Este exemplo s trava em gravaes de novos registros, e no trava em excluses:
Send Add_system_file ordsys dd_lock_on_new_save
Este exemplo trava em todas as excluses, mas no nas gravaes:
Send Add_system_file ordsys dd_lock_on_Delete
Este exemplo trava em gravaes de novos registros e em excluses (mas no em
edies):
Send Add_system_file ordsys dd_lock_on_new_save_delete
Observao: Voc pode adicionar vrios arquivos enviando vrias mensagens.
Send Add_system_file ordsys1
Send Add_system_file ordsys2
Voc pode remover um arquivo de sistema (o que raramente ser feito) com:

14
U
s
a
n
d
o

D
D
O
s

Send Remove_system_file ordsys
Cascade_delete_state
Cascade_delete_state especifica como uma excluso ser afetada pela existncia de
registros de arquivos filhos relacionados ao registro que est sendo excludo. Se
cascade_delete_state for true, ento os registros filhos e todos os descendentes sero
excludos. Se a propriedade for false, a excluso s ser permitida se no houver
registros filhos. Ambos os mtodos asseguram que os registros filhos nunca ficaro
rfos.
Voc pode alterar essa propriedade em tempo de execuo. Observe que podem ser
necessrias diferentes estruturas de dicionrio de dados para uma view que permita
cascade_delete e outra que no permita. A validao da estrutura que ocorre antes de
uma excluso verifica se a estrutura do dicionrio de dados est apropriada em relao
ao escopo da excluso.
send add_client_file to orderhea.file_number
set cascade_delete_state to false
:
Configurando as Propriedades do Campo
Uma propriedade do campo define uma propriedade para todos os itens DEO que
endeream um campo particular. Todas as propriedades do campo utilizam uma sintaxe
semelhante:
set field_options field_property_name field file.field to value
Onde field_property_name o nome da propriedade (a maioria dessas propriedades
comeam com o prefixo field_), e field uma palavra chave que indica que o valor
file.field a seguir a ele deve ser representado como um nmero de campo. A utilizao
da palavra chave field importante e discutida em sua prpria seo abaixo.
Field_Options
Define as regras e formatao que devem ser aplicadas aos DEOs que acessam esse
campo.
set field_options field customer.number to dd_noput dd_autofind

15
U
s
a
n
d
o

D
D
O
s

As opes listadas abaixo mostradas com um asterisco (*) so as opes de procura, e
s podem ser utilizadas em campos indexados. As outras opes podem ser utilizadas
em qualquer campo.
DD_AutoClear
DD_AutoBack
DD_AutoFind*
DD_AutoFind_GE*
DD_AutoReturn
DD_CapsLock
DD_DisplayOnly
DD_FindReq*
DD_ForcePut
DD_NoEnter
DD_NoPut
DD_Retain
DD_Retain_All
DD_Required
DD_SkipFound
DD_Zero_Suppress
Procura Automtica
DD_Autofind executa um find eq (procura igual) no ndice principal do campo. Se a
procura desejada for em um ndice de vrios segmentos, o autofind deve estar no
campo que for o ltimo segmento do ndice (DD_Autofind utiliza o ndice principal para
esse campo), para que todos os dados necessrios para a procura tenham sido
inseridos. Se o DD_Autofind for aplicado a um campo cujo ndice principal incluir o
nmero do registro, ele no funcionar.
Procura Automtica Maior ou Igual A
DD_Autofind_ge executa um find Greater than or Equal (procura Maior ou Igual) no
ndice principal do campo. Se o find ge desejado estiver em um ndice de vrios
segmentos, o DD_Autofind_ge deve estar no campo do ltimo segmento do ndice,

16
U
s
a
n
d
o

D
D
O
s

para que todos os dados necessrios para a procura tenham sido inseridos antes da
execuo. Os forms ou colunas dos dados dos arquivos relacionados tambm sero
preenchidos. O DD_Autofind_ge sempre ir encontrar um registro a no ser que o
arquivo esteja vazio.
Pula se Encontrar
DD_Skipfound verifica se o registro do buffer foi trazido por um comando find e, caso
tenha sido, no permite que o cursor ser posicionado no form ou coluna anexada a
esse campo. Em ambientes sem mouse, o cursor ir pular o form ou coluna para o
primeiro ou a primeira que no possuir essa opo. Esta opo foi feita para evitar
alteraes dos dados nos campos onde houver registros existentes, e permite o acesso
ao campo para a criao de novos registros.
Encontrar Requerido
DD_Findreq requer que um registro buscado do banco de dados esteja no buffer antes
que os usurios possam envi-lo no DEO. Isso no suportado no Windows, mas
suportado no DataFlex para a utilizao em ambientes que no suportam o mouse. O
cursor permanecer nessa janela at que uma procura tenha sido bem sucedida. A tecla
de acelerao Previous (Anterior) pode mover o cursor na ordem inversa para executar a
procura em outro item. O pressionamento da tecla de acelerao Clear (Limpar) far
com que o cursor retorne para o primeiro item do painel ou tela.
Colocar Dados Incondicionalmente
DD_Forceput insere dados do DEO no buffer do registro sem levar em considerao se
qualquer dado foi alterado em relao ao que foi exibido originalmente. Geralmente, os
dados inalterados do DEO no so movidos para o buffer do registro.
No Colocar os Dados
DD_Noput evita que os dados do DEO sejam inseridos no buffer do registro. Isso
protege os dados do disco que no devem ser alterado pelos usurios.
Sem Entrada de Dados
DD_Noenter impede a edio do contedo de um form ou coluna ao qual foi aplicado.
Em ambientes que no h mouse, ele posiciona o cursor no item seguinte, pulando o
atual, evitando assim qualquer entrada. O DD_Noenter pula o item mesmo se no for
encontrado registro, diferentemente do DD_Skipfound (veja acima).

17
U
s
a
n
d
o

D
D
O
s

Somente Exibio
DD_Displayonly a combinao do DD_Noput e do DD_Noenter listados acima. Em
ambientes que no h mouse, ele posiciona o cursor no item seguinte (pulando o atual),
e evita a insero de dados no buffer do registro.
Mantm Exibio da J anela
DD_Retain mantm os dados no DEO mesmo se um clear for executado, mas permite
que o item seja limpo se forem executados dois clears seguidos.
Mantm Exibio da J anela Sempre
DD_Retainall mantm os dados no DEO sempre; ele nunca permite que o item seja
limpo.
Entrada Requerida
DD_Required mantm o cursor no DEO at que algum dado seja inserido. O cursor no
avanar para o prximo item se no for digitado algo.
V para a J anela Anterior
DD_Autoback move o cursor para a ltima posio do DEO anterior quando a tecla seta
para a esquerda for pressionada na primeira posio do item.
V para a Prxima J anela
DD_Autoreturn move o cursor para o prximo DEO quando o DEO estiver completo.
Limpa J anela Automaticamente
DD_Autoclear no suportado no Windows, mas suportado no DataFlex para
ambientes no-Windows. Nesses ambientes, ele limpa o contedo existente do DEO
quando alguma entrada feita ao primeiro caractere do item. Se a tecla seta para a
direita for pressionada e a entrada for feita nas posies depois da primeira, esta
propriedade no tem efeito. Ela foi feita para facilitar a substituio de todo o contedo
de uma janela quando for desejado. Seu comportamento padro no Windows.
Letra Maiscula
DD_Capslock converte toda os caracteres alfabticos que estiverem em letra minscula
no DEO para letra maiscula.

18
U
s
a
n
d
o

D
D
O
s

Zeros vazios
DD_Zero_suppress substitui os valores zero em itens Numricos com espaos,
eliminando a exibio de zero e de um ponto decimal que os itens Numricos produzem
sem esta opo. Se um valor no for exatamente zero, mas a preciso do campo fizer
com que seja exibido zero, o zero ser exibido mesmo que esta opo seja utilizada.
:
set field_options field customer.id to dd_noput dd_autofind
dd_capslock
set field_options field customer.balance_due to dd_displayonly
Geralmente devem ser configuradas vrias opes para um nico campo. Voc pode
configurar todas com apenas uma mensagem, pode criar mensagens individuais para
cada opo, ou pode misturar as duas tcnicas. O exemplo a seguir equivalente ao
exemplo acima:
:
set field_options field customer.id to dd_noput
set field_options field customer.id to dd_autofind
set field_options field customer.id to dd_capslock
set field_options field customer.balance_due to dd_displayonly
Duas mensagens adicionais so suportadas para permitir que as opes do item sejam
limpas:
DD_clear_field_options limpa as opes do item enviadas por essa mensagem.
DD_clear_all_field_options limpa todas as opes de item para esse campo.
Procedure Define_Fields
:
// limpa a opo de item noput (se estiver configurada)
Set Field_Options Field Customer.ID to DD_CLEAR_FIELD_OPTIONS
DD_NoPut
// limpa todas as opes de item para esse campo
Set Field_Options Field Customer.Number to DD_CLEAR_ALL_FIELD_OPTIONS
Essas mensagens raramente so utilizadas.

19
U
s
a
n
d
o

D
D
O
s

Foreign_Field_Options (Opes de Campo Estrangeiro)
O comando entry_item associa um de arquivo e campo de dados a um form ou coluna.
Esse arquivo de dados ser o arquivo principal do dicionrio de dados do DEO, ou um
arquivo pai. Quando utilizado com um arquivo pai, considera-se o entry_item como
conectado a um campo estrangeiro. importante entender o conceito de um campo
estrangeiro. O exemplo a seguir mostra um entry_item que no estrangeiro seguido
por um entry_item estrangeiro:
object ef1 is a dbForm
set server to (orderhea_dd(current_object))
entry_item orderhea.order_number // este no um campo estrangeiro
:
object ef2 is a dbForm
set server to (orderhea_dd(current_object))
entry_item customer.number // este um campo estrangeiro
:
Quando um nmero de arquivo no o mesmo que o nmero do arquivo principal do
dicionrio de dados, geralmente o arquivo um ancestral (pai, av, etc.). Se no for,
provavelmente voc cometeu um erro. Freqentemente, os entry_items do arquivo
ancestral so utilizados diferentemente dos entry_items do arquivo principal. Durante a
entrada de um novo registro no arquivo principal, os registros do arquivo pai no so
modificados. Sua funo fornecer valores do campo (nmero do cliente, etc.) sobre os
quais as relaes so baseadas do arquivo principal para o ancestral. Quando o arquivo
pai precisa ser alterado (adicionar, excluir, modificar) isso feito em uma view
diferente, na qual esse arquivo o arquivo principal do DDO.
Por isso, geralmente os campos estrangeiros necessitam de configuraes de
propriedades de campo diferentes. A propriedade foreign_field_options permite que
voc atribua propriedades adicionais ao campo quando este for acessado em views
onde seu arquivo for estrangeiro.
Apesar das opes de campo estrangeiro poderem ser atribudas a campos individuais,
existe uma maneira mais conveniente de configurar essas opes de campo. Trs
designadores de tipo especiais podem ser utilizados para atribuir as opes de campo
estrangeiro a todos os campos de um tipo de campo especificado. Esses tipos so key
fields, index fields, e non-index (default) fields. As palavras chave utilizadas para
designar esses tipos de campo so DD_keyfield, DD_indexfield, e DD_default. Isso
mais fcil que ter que configurar as opes de campo estrangeiro para cada campo de
seus arquivos de dados.

20
U
s
a
n
d
o

D
D
O
s

:
set field_options field customer.id to DD_noput DD_autofind
DD_capslock
set field_options field customer.balance_due to DD_displayonly
:
// define as opes padres do campo estrangeiro
set foreign_field_options dd_keyfield to DD_findreq
set foreign_field_options dd_indexfield to DD_noput
set foreign_field_options dd_default to DD_displayonly
As propriedades do campo estrangeiro so adicionadas a quaisquer propriedades do
campo que tenham sido aplicadas diretamente ao mesmo. No exemplo acima, as
opes do campo cust omer . I d (campo no-estrangeiro) sero noput, autofind e
capslock. Suas opes de campo estrangeiro sero noput, autofind, capslock e, visto
que um key field, findreq.
Campos Chave
Campos Chave so campos que foram designados unicamente para identificar registros
em um banco de dados (nmeros do cliente em um arquivo cl i ent e, por exemplo). A
propriedade utilizada para designar os key fields key_field_state. Depois que voc
tiver designado os campos chave, deve configurar as opes para todos eles com
foreign_field_options.
Procedure define_fields
:
set key_field_state field customer.id to true
:
set foreign_field_options DD_keyfield to DD_findreq
Key_Field_State
A configurao da key_field_state do campo identifica este como sendo parte da chave
primria do arquivo. Esta informao utilizada para proteger os campos chaves e para
aplicar as opes de campo estrangeiro aoa campos chave como um grupo (tipo). Um
arquivo de dados pode possuir uma chave primria. Esta chave pode consistir de vrios
campos. Cada campo chave deve possuir seu key_field_state configurado para true.
:

21
U
s
a
n
d
o

D
D
O
s

set field_options field customer.id to dd_noput dd_autofind
dd_capslock
set key_field_state field customer.id to true
Protect_key_state
Protect_key_state determina se os campos que compe uma chave primria devem ser
protegidos depois que tiverem sido gravados pela primeira vez em um novo registro.
Quando estiver configurada para true, um campo identificado como sendo parte de uma
chave no pode ser editado depois que tiver sido gravado. Isso assegura que os
registros filhos que se relacionam com o pai atravs de uma chave primria no se
tornem rfos. Os campos que constituem uma chave primria so identificados
utilizando a propriedade de campo key_field_state.
send add_client_file to orderhea.file_number
set cascade_delete_state to false
set protect_key_state to true
:
Auto-incremento
Para atribuir uma chave nica, ou identificador, de um arquivo de sistema para novos
registros (quando so criados), utilize o comando define_auto_increment na procedure
define_fields.
define_auto_increment ordsys.cust# to customer.number
Neste exemplo, o Campo cust # do Arquivo de Sistema or dsys designado para
incrementar e fornecer um valor ao Campo number do Arquivo Principal cust omer sempre
que um novo registro for gravado em cust omer . Apenas um campo pode ter auto-
incremento em um arquivo principal.
Opes de Validao do Campo
Uma grande variedade de opes de validao podem ser aplicada a um campo. Trs
dos tipos de validao mais freqentemente utilizados podem ser definidos em uma
nica mensagem de validao. So eles:

22
U
s
a
n
d
o

D
D
O
s

check (o valor inserido deve coincidir com o item da string de
verificao)
range (o valor inserido deve estar entre um intervalo numrico ou de
data) e
checkbox (o valor inserido deve ser um de dois valores geralmente
utilizado em checkboxes)
Voc tambm pode definir uma validationTable. Cria-se um objeto de tabela de
validao e depois se atribui o objeto ao campo atravs da configurao da propriedade
field_value_table. Essa tabela utilizada para armazenar uma lista de itens vlidos. Um
campo utiliza esses valores para a validao (opcional) ou como um meio de fornecer
uma lista de valores de sugesto (combo boxes sero preenchidas com esses valores).
So fornecidos vrios tipos de tabelas de validao. Uma tabela muito til a tabela de
cdigo. Esta tabela pega seus valores de um simples arquivo Cdigo. Um arquivo de
cdigo contm registros que consistem de um tipo, um cdigo, e uma descrio.
Atravs da especificao de um tipo, a tabela fornece todos os cdigos e descries
vlidos para esse tipo.
A field_validate_msg permite que voc atribua uma mensagem a ser enviada quando
um campo precisar ser validado. Essa mensagem (geralmente uma funo) ser
chamada sempre que uma validao for necessria, e sero passados os seguintes
dados: nmero do campo e valor atual do campo. Se for detectado algum erro, a funo
deve gerar um erro e retornar um valor diferente de zero.
Normalmente todos os campos em todos os arquivos que participam de uma gravao
sero validados. Isso inclui os campos que no possuem representao visual na view
atual e todos os campos em todos os arquivos ancestrais. Na maioria dos casos, esse
nvel de proteo de dados desejado, e uma caracterstica poderosa do dicionrio de
dados. Em casos raros, voc pode querer uma menor proteo de validao. A
propriedade validate_foreign_file_state determina se a validao de campo deve ser
aplicada aos arquivos estrangeiros (ancestrais). Geralmente voc ir querer esse nvel
de validao, e por isso seu padro true. A configurao de seu valor para false far
com que no seja feita a validao em um campo quando o arquivo for utilizado como
um arquivo pai em sua estrutura de objetos data-server. Ela tambm suprime a
validao em todos os arquivos ancestrais adicionais. A propriedade
validate_deos_only_state determina se a validao no nvel do campo deve ser
aplicada a todos os campos ou apenas a campos visveis. Quando for true, a validao
do campo s ocorrer em campos que possurem um componente de interface com o
usurio. Isso deve fazer com que seus DataDictionarys se comportem de uma forma
semelhante aos objetos DataSet, onde a validao s aplicada a itens de entrada
visveis.

23
U
s
a
n
d
o

D
D
O
s

A configurao dessas propriedades fora de seu padro acaba com a validao total do
campo e compromete potencialmente a integridade dos dados. Elas s devem ser
configuradas dessa forma sob circunstncias cuidadosamente controladas. Por que voc
configuraria essa propriedade fora do padro? Durante a converso das aplicaes dos
data sets para os dicionrios de dados, voc pode achar que os nvel extra de
validaes esto gerando erros nos registros existentes. Nesse caso, voc pode querer
desabilitar algumas validaes at que esses problemas sejam corrigidos. Em outros
casos, voc pode achar que limitando as validaes, haver um ganho na performance.
IMPORTANTE: No utilize essas propriedades como atalhos para resolver o mau
planejamento do banco de dados. Regras de validao condicionais especiais podem
ser programadas diretamente em suas rotinas de validao. Por exemplo, voc pode
construir uma rotina de validao que s se aplica a novos registros (verifique os status
do registro com a propriedade current_record) ou pode criar rotinas de validao que
pulem certos campos quando forem estrangeiros (a varivel inteira global
operation_origin diz qual DDO iniciou a gravao). Ao invs de quebrar uma regra,
tente definir essa alterao da regra como parte de sua configurao de regra. No final,
voc ter uma aplicao melhor e mais robusta.
Field_Value_Range
Esta mensagem utilizada quando os valores vlidos do campo esto limitados a um
intervalo de nmeros ou datas. Essa propriedade configurada com um valor mnimo e
um mximo que definem o intervalo. Se o valor do campo estiver fora do intervalo, ser
gerado um erro. Alm de serem utilizados para validao, esses valores mnimo e
mximo tambm podem ser utilizados com itens de entrada spin-button. Se um
dbSpinForm for atribudo a um campo que utiliza intervalo de valores, o intervalo do
spin estar limitado ao atribudo no dicionrio de dados com essa propriedade.
:
set field_value_range field customer.discount to 0 60
Quando ocorre um erro de validao, o nmero e a mensagem de erro do campo
especificados pela propriedade field_error sero utilizados para gerar um erro. Se
nenhuma mensagem for especificada, um aviso padro de erro ser gerado.
Field_Checkbox_Values
Quando um valor vlido limitado a duas opes, voc deve definir esses valores com a
propriedade field_checkbox_values. Ela define os dois valores como um valor
verdadeiro e um valor falso, e define o campo como um checkbox. Os campos checkbox
podem ser utilizados em entry forms normais (onde os usurios devem inserir um dos

24
U
s
a
n
d
o

D
D
O
s

dois valores vlidos) ou com um item de entrada checkbox (nesse caso um checkbox
criado para representar o estado do campo). Isso torna muito fcil inserir objetos de
entrada checkbox em suas views. Simplesmente crie o objeto checkbox e d um rtulo a
ele. O dicionrio de dados manipular a converso dos valores do campo para os
estados de exibio do checkbox.
:
set field_checkbox_values field customer.status to A I //
ativo/inativo
Field_Value_Check
Esta mensagem utilizada quando a lista de valores vlidos do campo est limitada a
um conjunto de valores estticos. Esses exemplos so identificados em uma string de
verificao. Consiste em uma lista de valores vlidos separados pelo smbolo |. Por
exemplo, as opes A, B e C devem ser representadas pela string A|B|C. As opes
CA, FL, e TX seriam representadas pela string CA|FL|TX. Alm de serem utilizados para
a validao, esses valores tambm podem ser utilizados com combo-boxes. Se um
dbComboForm for atribudo a um campo que utiliza valores de verificao, cada valor
da string ser inserido na lista da combo box.
:
set field_value_check field customer.region to N|S|E|W
set field_value_check field customer.state to CA|FL|NY|AZ
Provavelmente, o exemplo cust omer . st at e acima no uma boa utilizao deste mtodo
de validao. Para adicionar novos estados a essa lista necessrios que se faam
alteraes no programa, e a string pode se tornar muito grande, o que no seria prtico.
Nesse caso, melhor utilizar a tabela de validao para fornecer os valores.
Field_Value_Table
Se um campo precisar ser validado em relao a dois valores, um conjunto limitado de
valores, ou um intervalo de valores, voc pode utilizar um dos mtodos estendidos de

25
U
s
a
n
d
o

D
D
O
s

validao j detalhados (field_checkbox_values, field_value_check e
field_value_range). Em muitos casos voc ver que esses tipos de validao tambm
so limitados em relao s suas necessidades. Nesse caso, melhor utilizar o tipo de
validao field_value_table.
A utilizao de uma tabela de validao de campo possui as seguintes vantagens:
voc pode especificar um grande nmero de valores vlidos que
podem se encaixar facilmente em uma string de verificao
voc pode especificar e exibir uma descrio para cada valor de sua
lista
voc pode manter sua lista de valores dinamicamente (ex.: os valores
no precisam ser codificados diretamente em seu programa)
voc pode fazer com que essa lista contenha escolhas opcionais (ou
seja, voc pode exibir uma lista de valores de sugesto durante a
entrada de dados, mas os usurios no precisam fazer uma seleo a
partir da lista)
A utilizao das tabelas de validao fornece uma tremenda flexibilidade. Elas sero
discutidas em detalhes em uma seo posterior. Por enquanto, introduziremos as
classes primrias das tabelas de validao:
ValidationTable
Esta classe permite que voc mantenha uma lista de valores vlidos.
Object Status_Table is a ValidationTable
Procedure Fill_List
Send Add_table_value O
Send Add_table_value C
Send Add_table_value D
end_Procedure
End_Object
DescriptionValidationTable
Esta classe permite que voc mantenha uma lista de valores vlidos e suas descries
correspondentes.
Object Status_Table is a DescriptionValidationTable
Set List_Title to Customer Status
Procedure Fill_List

26
U
s
a
n
d
o

D
D
O
s

Send Add_table_value O Opened
Send Add_table_value C Closed
Send Add_table_value D Flagged for Deletion
end_Procedure
End_Object
FileValidationTable
Esta classe permite que voc mantenha uma lista de valores e descries que podem
ser carregadas facilmente a partir de um arquivo de dados DataFlex especificado .
Exemplo:
Object Status_Table is a FileValidationTable
Set Main_File to CustStat.File_Number
End_Object
CodeValidationTable
Esta classe permite que voc carregue seus dados e descries a partir da Lista de
Cdigos DataFlex.
Exemplo:
Object Status_Table is a CodeValidationTable
Set Type_Value to Status
End_Object
Quaisquer das tabelas de validao acima podem ser vinculadas a um campo com a
mensagem field_value_table em um dicionrio de dados.
Set Field_Value_Table Field Customer.Status to
(Status_Table(Current_Object))
Field_Validate_Msg
Isto permite que voc atribua uma mensagem com propsito geral a ser enviada quando
um campo tiver que ser validado. Essa mensagem (geralmente uma funo) ser
chamada sempre que seu programa solicitar uma validao. Esse mtodo de validao
utilizado quando se precisa executar validaes complexas que s podem ser
expressas com codificao. Visto que um processo muito aberto, ele pode fazer quase
tudo. Se o valor for vlido, a funo deve retornar zero. Se o valor for invlido, a funo
deve gerar um erro e retornar um valor diferente de zero.

27
U
s
a
n
d
o

D
D
O
s

Voc deve criar funo(es) de validao. Essa funo receber o nmero do campo e o
valor do campo atual. Sua funo pode utilizar esses valores conforme achar adequado.
Para esse propsito, o valor de qualquer outro campo do dicionrio de dados pode ser
obtido pegando o valor da propriedade field_current_value. Deve-se observar que a
rotina de validao nunca deve acessar um valor no DEO. A informao necessria deve
ser procurada no DDO ou em um dos DDOs conectados a ele.
:
set field_validate_msg field employee.pay_type to get_valid_pay_type
Os mtodos para validao de campo com propsitos especiais (field_value_check,
field_value_range, field_checkbox_values e field_value_table) so mutuamente
exclusivos. No entanto, uma mensagem field_validate, pode ser utilizada em adio a
qualquer mtodos de validao de propsitos especiais (isto ser um caso raro).
Field_Error
Permite que voc defina um nmero e mensagem de erro personalizados para um
campo. As validaes de intervalo, verificao, checkbox, e de tabela exibiro essas
mensagens quando uma validao falhar. Voc pode utilizar essas mensagens dentro
de uma funo field_validate_msg personalizada enviando a mensagem field_error.
:
set field_checkbox_values field customer.status to A I //
ativo/inativo
set field_error field customer.status to 900 value must be A or I
Field_Entry_Msg / Field_Exit_Msg
Estas mensagens so semelhantes field_validate_msg e so enviadas sempre que o
cursor entra ou sai de um item conectado a um campo. Voc deve criar as procedures e
depois atribuir os nomes da procedure s propriedades do campo. Quando chamadas,
as procedures enviam o nmero e o valor do campo. Embora o retorno de um valor
diferente de zero pare a navegao, isso no ser muito utilizado. Essas procedures so
freqentemente utilizadas para manipular o processamento anterior entrada e posterior
sada.
Status_Help
Define uma linha de texto de status-help para o campo. Os objetos de entrada a
utilizaro para exibir a ajuda na barra de status.

28
U
s
a
n
d
o

D
D
O
s

Exemplo:
:
set status_help field cust.status to A customer is either Active or
Inactive
Field_Prompt_Object / Field_Zoom_Object
Essas propriedades associam objetos de prompt ou de zoom aos campos. O
field_prompt_object permite que voc associe uma prompt list a um campo. Isso
necessrio quando voc possui uma lookup relacional. Se voc estiver utilizando tipos
de validao estendidos (check, checkbox, ou qualquer tabela de validao), o dicionrio
de dados inteligente o suficiente para fornecer uma prompt list padro. Ele faz isso se
no houver nenhuma prompt list explicitamente atribuda. Ento, se voc atribuir um
field_prompt_object para um campo, ele ser utilizado no lugar da prompt list fornecida
para validaes estendidas.
:
set field_prompt_object field customer.name to
(cust_lkup(current_object))
Configurando Padres
Voc pode configurar as propriedades padres de campo e os valores que os campos
iro conter antes que os usurios insiram os dados.
Definindo os Padres do Campo
A procedure field_defaults fornecida para fornecer a configurao dos valores
padres depois de um clear. Voc pode configurar qualquer valor do campo, o qual ser
refletido no DEO e ser gravado com o novo registro. Como a configurao de padres
configurada em uma procedure, ela permite regras complexas. A configurao de um
padro no reconhecida como uma alterao de dados pelo dicionrio de dados; por
isso, essa configurao no ir gerar a mensagem de erro data-loss. Os padres
tambm podem ser configurados em um item de entrada de dados atravs da
configurao das propriedades field_entry_msg e field_default_value.
Exemplo 1:
Procedure Field_Defaults
Set Field_Changed_Value field customer.state to CA
Set Field_Changed_Value field customer.discount to 10

29
U
s
a
n
d
o

D
D
O
s

Set Field_Changed_Value field Customer.City to Miami
End_Procedure
Exemplo 2:
Set Field_Entry_Msg field ORDERHEA.ORDER_DATE to Entry_Order_Date
Utilizando os Parmetros de Mensagem Field File_Field
Antes um campo podia ser acessado atravs de uma propriedade ou mensagem apenas
pelo nmero do campo em seu arquivo. Vrios comandos tornam esse processo mais
simples. Um comando especial chamado get_fieldnumber pode ser utilizado para
extrair um nmero do campo de um file.field. Ele possui o seguinte formato:
get_fieldnumber f i l e. f i el d to f i el d_num
Ele pode ser utilizado da seguinte maneira:
get_fieldnumber customer.name to custname
set field_options item custname to DD_autofind
Como esse tipo de acesso ser necessrio freqentemente nos dicionrios de dados,
um parmetro especial do comando foi feito para suportar isso com uma nica
mensagem. Quando a palavra chave field for utilizada, os nomes file.field que a seguem
sero convertidos no nmero do campo. O exemplo acima poderia ser reescrito da
seguinte forma:
set field_options field customer.name to DD_autofind
As mensagens file_field_ requerem que um nmero de arquivo e um nmero de campo
sejam passados. Isso poderia ser feito conforme a seguir:
get_fieldnumber customer.name to custname
set file_field_current_value customer.file_number custname to John
Uma palavra chave, file_field, permite que voc reduza isto como a seguir:
set file_field_current_value file_field customer.name to John
Raramente voc precisar utilizar as mensagens file_field_ e por isso raramente
utilizar a palavra chave file_field. As mensagens Field_ que sempre so utilizadas com
a palavra chave field sero usadas extensivamente. Voc deve lembrar de utilizar essa
palavra chave. Se voc omiti-la ou utilizar a palavra chave item no seu lugar, receber
um resultado muito diferente.
Construindo Subclasses Data-Dictionary
Uma aplicao pode consistir de vrias views que precisam do mesmo arquivo de
dados. Por exemplo, uma views de cadastro de produtos e outra views para cadastro de

30
U
s
a
n
d
o

D
D
O
s

fornecedores precisaro utilizar o arquivo de dados fornecedor. Cada uma dessas views
tero um DDO separado baseado em seu arquivo de dados para fornecer os servios
necessrios. Apesar desses DDOs serem baseados no mesmo arquivo, eles sero
independentes. As alteraes em uma view no afetaro os dados da outra. O
encapsulamento ir garantir isso. Apesar desses DDOs serem independentes, eles
compartilham vrias caractersticas em comum. As regras do banco de dados para
esses objetos devem ser as mesmas. Quaisquer regras especiais para o arquivo de
dados devem ser obedecidas por todos os DDOs baseados nesse arquivo. Essas regras
pertencem a uma subclasse especfica para o arquivo. Todos os DDOs desse arquivo
devem ser baseados nessa subclasse.
A Subclasse Data-Dictionary mais Simples
O arquivo de banco de dados do DDO especificado em uma propriedade chamada
main_file. Se voc no fizer nada mais, sua subclasse data-dictionary deve configurar
essa propriedade main_file. Dessa maneira voc no ter que identificar o nome do
arquivo no objeto. O exemplo a seguir mostra como uma subclasse DataDictionary
deve ser criada para um arquivo de dados.
Se a subclasse baseada na classe DataDictionary
Class Vndr_DataDictionary is a DataDictionary
Forward Send Define_Fields
Set main_file to Vndr.File_Number // identify file #
end_procedure
end_class
Se a subclasse baseada na classe dataSet.
Class Vndr_DataDictionary is a DataSet
Procedure construct_object
Forward Send construct_object
Set main_file to Vndr.File_Number // identify file #
end_procedure
end_class
Ento seu objeto deve ser:
Object Vndr_DD is a Vndr_DataDictionary
end_object

31
U
s
a
n
d
o

D
D
O
s

Provavelmente voc manter o cdigo de sua subclasse em seu prprio arquivo
package (com uma extenso .DD), utilizando esse arquivo a partir de qualquer
programa que precisar criar DDOs baseados nessa classe (isto , os que utilizam esses
arquivos e as mesmas regras para seus dados). Dependendo do tamanho de sua
aplicao, voc pode optar por posicionar cada subclasse data-dictionary em seu prprio
arquivo package ou pode optar por inserir todas as subclasses data-dictionary em um
nico arquivo package. Inserindo a classe em um arquivo package, voc pode alterar
suas regras do arquivo de dados atravs da alterao e um nico arquivo e aps isso,
recompilando todos os programas que utilizam esse arquivo package.
O main_file para uma subclasse data-dictionary o arquivo de banco de dados que esta
subclasse deve controlar. Quando as operaes save, delete, clear, e find so
executadas para esse DDO, o registro do arquivo principal o registro afetado. Isso
importante quando se utiliza vrios DDOs: o DDO que o servidor para um DEO
determina as aes das teclas Save Record (F2), Delete Record (Shift+F2), e Clear (F5).
Quando essas teclas so pressionadas em um DEO, a mensagem enviada para o
DDO do DEO para executar a ao. As aes save, delete, ou clear so executadas
para o arquivo principal do DDO que receber o pedido. Isso ser discutido
posteriormente nesta seo.
As Mensagens de Operao do Dicionrio de Dados
Algumas subclasses data-dictionary permanecem to simples como o exemplo acima. A
classe DataDictionary suporta vrias mensagens que permitem que voc controle
vrios comportamentos de uma gravao, excluso, procura, e limpeza. Ns as
chamamos de mensagens gancho. Antes de discutirmos como utilizar as mensagens
gancho em suas subclasses data-dictionary, precisamos discutir as principais operaes
dos dicionrios de dados.
A principal funo dos dicionrios de dados gravar, excluir, limpar, e procurar registros.
Apesar dessas funes sempre se originarem com um simples pedido de um DDO,
esses pedidos se propagam sobre toda a estrutura do dicionrio de dados (todos os
DDOs que estiverem conectados atravs de set ddo_server e todos os DEOs que
estiverem conectados com esses DDOs atravs de set server). melhor pensar na
operao do dicionrio de dados em termos de toda a estrutura do mesmo e no como
um simples DDO.
As principais mensagens de operao do dicionrio de dados e suas funo so
descritas resumidamente aqui. Essas mensagens so pblicas, o que significa que so
mensagens apropriadas para serem enviadas a um DDO e so candidatas apropriadas
para personalizao. Na prtica, voc ver que raramente essas mensagens so
enviadas explicitamente. Os DEOs faro isso para voc atravs de suas definies de
classe. Alm disso, voc ver que raramente se personaliza essas mensagens. Por

32
U
s
a
n
d
o

D
D
O
s

outro lado, as mensagens gancho do dicionrio de dados, so freqentemente
customizadas.
As Mensagens Clear e Clear_all
Essas mensagens so responsveis pela limpeza das estruturas do dicionrio de dados.
A mensagem clear limpa alguns DDOs em uma estrutura, enquanto a mensagem
clear_all limpa todos os DDOs em uma estrutura. Veja a seo Propagao das
Operaes do Dicionrio de Dados para determinar quais DDOs so limpos. Depois de
uma limpeza, todos os DEOs participantes so atualizados.
As Mensagens de Procura
Existem vrias mensagens de procura suportadas pelos DDOs. As principais mensagens
so: request_find, request_superfind, e find_by_recnum. O objetivo dessas
mensagens mover os dados dos DEOs para o buffer do arquivo, executar a operao
de procurar apropriada, e atualizar os DEOs com os valores dos registros mais novos
encontrados. A operao de procura em um DDO afetar outros DDOs em uma
estrutura. Os registros pais esto relacionados e algumas vezes so encontrados
registros filhos. Todos os DDOs e DEOs so notificados conforme necessrio.
A Mensagem Request_save
Quando a operao save executada por um DDO, o registros so gravados no arquivo
principal bem como os arquivos em seus DDOs atualizados. Isso permite que
atualizaes em campos de totais de arquivos relacionados sejam executadas conforme
cada registro no main_file criado ou editado. Essa ao tambm causa a criao de
novos registros em qualquer um dos arquivos. Qualquer buffer de registro que no
estiver apontando para um registro j existente ter um novo registro criado. Como um
exemplo, quando se insere um novo registro de pedido, pode ser desejvel adicionar o
(novo) cliente para esse pedido ao mesmo tempo. Como voc listou o arquivo cliente
como um dos DDOs atualizados, o novo registro cliente pode ser criado
automaticamente quando o pedido (o arquivo principal) for gravado.
A mensagem request_save responsvel pela gravao de registros novos ou
existentes. Uma request_save ir:
Travar os arquivos de dados necessrios.
Fazer um reread e backout (e gravar se necessrio) todos os dados originais.
Mover todos os dados alterados dos DEOs para o buffer do arquivo.
Enviar creating para todos os DDOs com novos registros.

33
U
s
a
n
d
o

D
D
O
s

Enviar update para todos os DDOs participantes.
Chamar a validate_save de todos os DDOs participantes. Se qualquer
validate_save falhar, a operao ser cancelada.
Se todos os DDOs forem validados, ocorrer um attach e save para todos os
registros (attach_main_file, save_main_file).
Destrava os arquivos de dados.
Atualiza todos os DEOs participantes.
Se a validate_save falhar ou se um erro for gerado, a gravao desfeita e os arquivos
de dados e DDOs so restaurados para seus contedos originais.
A Mensagem Transaction_aborted
A mensagem transaction_aborted enviada quando uma gravao cancelada pela
validate_save. Se a gravao foi cancelada pela validate_save retornando um nmero
diferente de zero, esse nmero ser enviado para a transaction_aborted. Se a
gravao foi cancelada pela validate_save gerando uma mensagem de erro, o valor
enviado para a transaction_aborted ser zero. Neste caso, voc pode ler o inteiro
last_err para saber que erro foi gerado. A transaction_aborted enviada depois que a
transao foi desfeita, os arquivos de dados foram destravados, e que a mensagem de
erro (se houver) tiver sido exibida. Como, agora, a transao desfeita automaticamente
no DataFlex, a necessidade da mensagem transaction_aborted diminuiu. Ela foi
mantida no produto para haver compatibilidade com verses anteriores.
A Mensagem Request_validate
Antes do objeto de entrada de dados enviar a mensagem request_save para seu DDO,
ele envia a mensagem request_validate. A Request_validate envia a mensagem
validate_items para todos os DEOs que iro participar da gravao. Se a validao de
qualquer item falhar, ser reportado um erro e a gravao no continuar.
Provavelmente, voc nunca enviar ou aumentar esta mensagem.
importante que voc entenda como esse processo ocorre. Antes de uma gravao,
cada item em cada DEO que participar da gravao ser validado. Essa uma
validao de pr-gravao. Seu banco de dados ainda no est travado. Essa validao
de item um processo diferente que a validao de gravao atual do DDO
(validate_save), que ocorre posteriormente no processo da gravao.

34
U
s
a
n
d
o

D
D
O
s

A Mensagem Request_delete
A mensagem request_delete responsvel pela excluso de um registro do DDO para
o arquivo principal, atualizando todos os DDOs (e arquivos) pais e possivelmente
excluindo todos os registros filhos. So suportados dois modos de excluso. Uma
excluso ir excluir todos os registros descendentes, ou impedir a excluso quando
houver registros filhos. A propriedade cascade_delete_state controla essa mensagem.
Para mais informaes veja Validate_delete_no_cascade e Cascade_delete_state.
Excluindo um Registro e todos os seus Filhos
Se o cascade_delete_state for true, a request_delete tentar excluir o registro do DDO
e todos os registros descendentes. Para isso funcionar, as seguintes condies devem
ser satisfeitas:
1. Todos os DDOs dos arquivos descendentes devem estar conectados
apropriadamente com a estrutura do data-server (com set ddo_server); e
2. Deve haver um relacionamento vlido entre os arquivos pais e filhos definidos
fisicamente (ou com um comando set_relate).
Quando essas condies so satisfeitas, ocorrer o seguinte:
Excluses quando o cascade_delete_state true:
Trava os arquivos de dados necessrios.
Rel todos os registros necessrios.
Chama a validate_delete do DDO principal. Se a validate_delete falhar,
cancela a operao.
Exclui todos os registros descendentes relacionados. Para cada registro filho:
o Envia deleting para o DDO principal.
o Envia backout para todos os DDOs pais.
o Grava todos os arquivos pais.
Envia deleting para o main DDO.
Envia backout para todos os DDOs pais.
Exclui o registro principal (delete_main_file)
Grava todos os arquivos pais

35
U
s
a
n
d
o

D
D
O
s

Prevenindo Excluses Quando houver Registros Filhos relacionados ao
Registro
Se o cascade_delete_state false, a request_delete no permitir que os usurios
excluam um registro quando houver registros filhos. Para esse processo funcionar, voc
deve listar todos os arquivos filhos (clientes) na subclasse data-dictionary. Isso feito
enviando a mensagem send add_client_file filename.file_number para cada
arquivo filho. No importa se esses arquivos filhos esto conectados estrutura do
dicionrio de dados.
No entanto, esses arquivos devem estar abertos (ou a excluso no ser permitida) e
deve haver um relacionamento vlido entre os arquivos pais e filhos definidos
fisicamente (ou atravs do comando set_relate). Quando essas condies forem
satisfeitas, ocorrer o seguinte:
Excluses quando o cascade_delete_state false:
Trava os arquivos de dados necessrios.
Rel todos os registros necessrios.
Chama validate_delete do DDO principal.
Verifica se h registros filhos ou arquivos fechados (get
validate_delete_no_cascade). Se uma das validaes falharem, a operao
cancelada.
Envia deleting para o DDO principal.
Envia backout para todos os DDOs pais.
Exclui o registro principal (delete_main_file)
Grava todos os arquivos pais.
Desfazendo uma Transao
Se uma operao de gravao ou excluso falhar por qualquer razo, toda a operao
(transao) de gravao ou excluso desfeita, e seus arquivos de dados e DDOs so
restaurados para sua condio original antes da operao ser executada. Geralmente
uma operao ser interrompida por uma falha na validate_save ou validate_delete.

36
U
s
a
n
d
o

D
D
O
s

No entanto, a ao tambm ser desfeita em qualquer momento que um erro for
encontrado durante o processo de travamento. Esse erro pode ser gerado pelo
desenvolvedor (com o comando error) ou pelo runtime (por exemplo, um erro de ndice
duplicado).
Erros nos Dicionrios de Dados
Se ocorrer um erro em um DDO durante um processo de travamento, acontecem duas
coisas: 1) o processo do DDO interrompido e a transao desfeita; e 2) a mensagem
de erro no gerada at que a transao seja desfeita e os arquivos de dados sejam
destravados. O adiamento da mensagem de erro assegura que o erro no ser
reportado enquanto os arquivos de dados estiverem travados. Quando um erro ocorre,
todo o processamento de cdigo para. As mensagens do DDO restantes no so
enviadas e o restante de cdigo de qualquer procedure ou funo no executado. No
exemplo a seguir, o cdigo que est aps o comando error na validate_save nunca
ser executado:
function validate_save returns integer
error 300 "We have an error"
// esses dois comandos nunca sero executados.
send bell
function_return 1
end_function
Se voc gerar um erro dentro da validate_save ou validate_delete, no h necessidade
de retornar um valor diferente de zero. O processo j foi interrompido.
Travamento Inteligente do Arquivo
Voc ir notar que o primeiro passo nas operaes de gravao e excluso travar os
arquivos necessrios. Geralmente, um lock ou reread faz com que todos os arquivos
de dados abertos sejam travados. Os DDOs suportam um tipo de travamento que s faz
lock e reread nos arquivos que participaro da operao de gravao ou excluso. Isso
pode resultar em um aumento significante na velocidade de processamento. O smart
filemode uma caracterstica automtica da classe data-dictionary. Nas subclasses
data-dictionary, o smart filemode deve ser habilitado configurando a propriedade
smart_filemode_state para true em todos os DDOs que participam da operao de
gravao ou excluso. Geralmente, isso seria configurado em sua subclasse data-
dictionary. Uma procedure adicional chamada reset_filemodes_for_lock pode ser
aumentada para manipular quaisquer condies especiais de travamento (como o
travamento de uma arquivo de sistema). Este importante tpico discutido em detalhes
posteriormente nesta seo.

37
U
s
a
n
d
o

D
D
O
s

Read_only_state
Muitas aplicaes utilizam um arquivo apenas para consulta. Nessas situaes, o
read_only_state do DDO deve ser configurado para true para que nenhuma operao
de gravao possa ser iniciada nesse DDO. Porm, se uma operao de gravao for
iniciada em um DDO cliente, o DDO servidor ser gravado, mesmo que o
read_only_state esteja configurado para true. Isso assegura a integridade do banco de
dados.
Utilizando as Mensagens Gancho
As mensagens gancho so assim chamadas, porque so elaboradas somente para
executar uma funcionalidade especial que voc pode precisar programar nas gravaes
ou excluses. Elas so ganchos nos quais voc pode pendurar procedures de sua
prpria definio. Voc s precisa dar s suas procedures o nome especial do gancho
que voc deseja utilizar. O DataFlex as envia automaticamente em certos pontos
durante as gravaes e excluses. Por padro, elas no fazem nada. Voc pode definir
essas procedures e utiliz-las para fornecer uma validao extra e para manipular
clculos em campos. Espera-se que voc utilize essas mensagens em suas subclasses.
Essas mensagens esto documentadas na Referncia de Classe do Visual DataFlex. As
procedures e funes gancho mais comuns so:
Validate_Save
utilizada como validao final de um registro antes de sua gravao. chamada
quando o banco de dados est travado e todos os valores atualizados. Voc pode
buscar diretamente o valor de qualquer buffer file.field e se qualquer combinao de
valores for invlida, interromper a gravao declarando um erro ou retornando um valor
diferente de zero. Isso no deve ser confundido com a validao do campo. A validao
do campo ocorre antes do banco de dados estar travado e antes dos campos serem
atualizados no buffer. A validao do campo pode ser utilizada para manipular a maioria
das validaes. A Validate_save utilizada para manipular as validaes especiais que
s podem ser verificadas em um estado de travamento e atualizao.
Validate_delete
utilizada para validar se uma excluso de registro pode ser executada. A declarao
de um erro ou o retorno de um valor diferente de zero ir interromper o processo.
Update / Backout / Creating / Deleting
So utilizadas para manter o equilbrio de clculos. So utilizadas para calcular totais em
tempo de execuo (update e backout) e para atribuir as IDs do sistema a novos
registros (creating).

38
U
s
a
n
d
o

D
D
O
s

Propagao de Mensagens Gancho
As mensagens listadas so enviadas a todos os objetos em uma estrutura data-server
que participaro de uma operao particular. A Validate_save, por exemplo, chamada
durante uma operao de gravao. Uma gravao envolve o DDO que iniciou a mesma
(o DDO que recebeu a mensagem request_save) e todos os DDOs que ela atualiza (a
gravao se propaga para cima). Durante uma gravao validate_save enviada para
todos estes objetos. Quando voc pensa nos comportamentos do DDO, tente pensar em
termos de comportamento das estruturas do dicionrio de dados e no como simples
DDOs.
Quando uma mensagem propagada em uma estrutura de dicionrio de dados, a ordem
na qual as mensagens so enviadas ir variar. Em alguns casos, uma mensagem ser
enviada para o DDO pai de todos (servidor) e se propagar para baixo para os DDOs
filhos (clientes). A mensagem save_main_file se propaga dessa maneira. Outras
mensagens so iniciadas no filho e se propagam para seus pais. As mensagens de
atualizao se propagam dessa maneira. Geralmente, tudo o que voc precisa saber
que a mensagem ser enviada para os DDOs corretos na ordem correta baseada na
funo da mensagem.
Forward de Mensagens Gancho
Muitas das mensagens gancho do dicionrio de dados no executam nenhuma ao por
padro. Elas so fornecidas para que voc possa construir suas prprias regras
personalizadas. Quando se aumenta uma dessas mensagens gancho, pode parecer
desnecessrio executar o forward send; o comportamento da mensagem de forward
seria fazer nada. Apesar de voc no precisar avanar essas mensagens, recomenda-se
que isso seja feito. uma boa prtica de programao orientada a objeto sempre
executar o forward send em uma mensagem, a no ser que voc queira cancelar esse
comportamento explicitamente. Todos os nossos exemplos iro executar forward send
para as mensagens (a no ser que cancelemos esse comportamento). Ento, apesar de
podermos codificar uma procedure da seguinte maneira:
procedure update
add order.total to customer.due
end_procedure
Iremos codific-la com um forward send:
procedure update
forward send update
add order.total to customer.due
end_procedure

39
U
s
a
n
d
o

D
D
O
s

As Mensagens Gancho de Validao
Validate_Save Function
A funo validate_save chamada exatamente antes de um registro ser gravado. Se
um DDO estiver conectado a outros DDOs, a mensagem validate_save ser enviada
para todos os DDOs que participaro desta gravao. Se qualquer uma dessas
chamadas retornar um valor diferente de zero, um erro gerado, ou a mensagem
operation_not_allowed enviada (a qual gera um erro), a gravao no ser efetuada.
Quando essas funes forem chamadas, todos os dados j foram movidos para todos os
buffers. Os dados do buffer de arquivos esto exatamente com o que dever ser salvo. A
nica exceo que os attachs dos arquivos ainda no ocorreram. Isso significa que
um buffer de arquivo filho pode conter a informao do pai que ser posicionada no
arquivo com um attach. O attach ocorre depois da validate_save.
Os arquivos de dados de todos os DDOs participantes esto travados durante a
validate_save. Por isso, a funo deve ser rpida e nunca pedir entrada do usurio. A
exceo a isso o comando error. Um erro gerado durante a validate_save s ser
exibido depois que toda a gravao tiver sido desfeita e os arquivos de dados
destravados. Isso s ocorre com erros gerados pelo comando error. Geralmente, uma
validate_save que falhar ir gerar uma mensagem de erro, como nos dois exemplo
abaixo.
Function validate_save returns Integer
local integer rval
If (Invt.Qty < 0) ;
Error 301 'Insufficient Inventory on hand'
forward get validate_save to rval
function_return rval
end_function

Function validate_save returns Integer
local integer rval
If (Invt.Qty < 0) ;
send operation_not_allowed 301
function_return rval
end_function

40
U
s
a
n
d
o

D
D
O
s

Como os buffers de todos os arquivos participantes foram atualizados, voc no deve
fazer nenhum find, clear, delete, ou alterar esses buffers de arquivo.
Validate_delete Function
Esta funo chamada antes de uma excluso ser efetuada. Os arquivos participantes
esto travados. Retornando um valor diferente de zero for retornado, gerando um erro,
ou enviando a mensagem operation_not_allowed (a qual gera um error) a excluso
ser interrompida.
Uma operao de excluso excluir o arquivo principal e todos os registros
descendentes relacionados (filho, neto, etc.). Isso ocorre para evitar que existam
registros rfos. Isso s ocorre se a cascade_delete_state true, se houver
relacionamento filho-pai entre os arquivos e se existir um relacionamento set
ddo_server entre os DDOs dos arquivos. Os constraints no tm nada a ver com isso.
A validate_delete s enviada para o DDO do arquivo principal onde a excluso est
sendo feita. Se a validate_delete aprovada, o registro do arquivo principal e todos os
registros dos arquivos filho sero excludos.
Se voc estiver proibindo excluses em cascata, vital que voc faa o forward sa
mensagem validate_delete. A verificao de excluso em cascata ocorre como parte do
comportamento padro dela:
Function validate_delete returns integer
local integer rval
forward get validate_delete to rval
if (rval <> 0) function_return rval
If (customer.Status = 'A') ;
send operation_not_allowed 306
end_function
Validate_delete_no_cascade e Cascade_delete_state
Voc pode no querer excluir registros que possuam filhos (mas, ao contrrio,
permitindo que registros sem filhos excludos). Geralmente no faz sentido permitir que
os usurios excluam este tipo de histrico. Alm disso, toda a operao de excluso
executada em um estado de travamento simples. Se estiver excluindo vrios registros
descendentes, voc pode estar impedindo que outros usurios efetuem locks no banco
de dados por um perodo inaceitvel.
Isso pode ser controlado com a propriedade cascade_delete_state e a mensagem
add_client_file. Quando o cascade_delete_state do DDO false, ele no permitir a

41
U
s
a
n
d
o

D
D
O
s

excluso de registros os quais possuam um arquivo filho nomeado em uma mensagem
add_client_file contendo registros que se relacionam ao registro que ser excludo.
Quaisquer registros relacionados em arquivos que no estiverem nomeados em uma
mensagem add_client_file no iro prever a excluso (e sero excludos).
A subclasse de exemplo a seguir impedir excluses se for encontrado um registro
relacionado em algum dos dois arquivos filhos (ou se o arquivo filho no estiver aberto).
Observe que no necessrio que os DDOs existam para os arquivos filhos; a
verificao de excluso em cascata, checa diretamente os arquivos, e no atravs dos
DDOs:
class customer_data_dictionary is a DataDictionary
procedure construct_object
forward send construct_object
set cascade_delete_state to false //no excluir se houver
filho
send add_client_file orderhea.file_number // arquivo filho 1
send add_client_file calbacks.file_number // arquivo filho 2
end_procedure // construct_object
:
end_class
A Validate_delete envia a mensagem validate_delete_no_cascade para que o citado
anteriormente funcione. Se voc fornecer sua prpria definio validate_delete
personalizada, essa definio deve conter uma declarao forward get
validate_delete to rVal para manter essa funo funcionando.
Se voc precisar verificar se existem registros filhos de um modo diferente do padro,
voc pode aumentar a validate_delete_no_cascade para executar essa tarefa. Quando
uma excluso em cascata falha, o erro reportado atravs do envio da mensagem
operation_not_allowed. Um dos dois nmeros de erro passado para esse
procedimento: 4139 Cannot delete - related files not open, and 4140 Cannot delete -
related records exist.
Mesmo se voc no tiver a inteno de utilizar a preveno de excluso em cascata,
recomendamos que voc liste todos os arquivos filhos necessrios em sua subclasse
com a mensagem add_client_file. As verses futuras dos dicionrios de dados sero
capazes de tirar proveito dessa informao, e podero necessitar dela.

42
U
s
a
n
d
o

D
D
O
s

Operation_not_allowed
Essa mensagem enviada sempre que um DDO recebe uma mensagem para executar
uma operao impossvel ou ilegal. A mensagem enviada com um parmetro, um
nmero de erro. Esse pode ser o nmero de um erro definido em seu programa, ou o
nmero de qualquer erro pr-definido do DataFlex. Essa mensagem centraliza a
manipulao de erros para os erros gerados nos DDOs, e apenas esses erros. Ela no
manipula erros gerados pelo gerenciador do banco de dados ou pelo cdigo definido
pelo usurio que no envia a mensagem operation_not_allowed.
A Operation_not_allowed pode ser aumentada para enviar mensagens de erro
personalizadas. Por exemplo, podemos alterar uma das mensagens de erro existentes
(4140 Can't delete - child records exist) e adicionar duas mensagens personalizadas
(301 Insufficient Inventory on hand, e 303 Can't delete active customer). Com isso,
supe-se que a validate_save e a validate_delete esto enviando a
operation_not_allowed e passando os nmeros de erro apropriados:
procedure operation_not_allowed integer err#
if err# eq 301 error err# "Insufficient Inventory on hand."
else if err# eq 303 error err# "Can't delete active customer."
else if err# eq 4140 error err# "- Customer has orders assigned."
else forward send operation_not_allowed err#
end_procedure
Mensagens de Atualizao da Base de Dados
As mensagens update, backout, deleting, e creating permitem que voc atribua e
mantenha o equilbrio de clculos durante uma operao de gravao ou excluso.
Estes podem ser contadores, IDs de registro, ou balanos relacionais. Todas essas
mensagens possuem algumas caractersticas em comum.
Voc deve ter certeza de que todos os arquivos referenciados nessas
procedures esto representados na estrutura de DDO e que os DDOs esto
interconectados apropriadamente com set ddo_server.
Voc no deve tentar interromper uma gravao ou excluso a partir dessas
procedures. No retorne um valor diferente de zero e no gere uma mensagem
de erro nas mesmas.
Essas mensagens so enviadas para todos os DDOs que participam da
gravao ou excluso. A ordem na qual essas mensagens so enviadas para os
DDOs varia dependendo do processo. No se preocupe com a ordem; os DDOs
fazem isso corretamente.

43
U
s
a
n
d
o

D
D
O
s

Essas mensagens so enviadas quando os arquivos de banco de dados
participantes esto travados e seus buffers contm a informao correta.
Procedures Update, Backout
Essas mensagens so utilizadas para manter equilbrios relacionais entre os arquivos de
dados. A Update chamada quando um registro est sendo gravado ou editado. A
Backout chamada quando um registro esta sendo editado ou excludo. Geralmente,
ambas iro ajustar os balanos dos arquivos pais. As procedures update e backout a
seguir de um DDO para o arquivo checks devero ajustar os balanos de seu pai, o
arquivo de dados vndr .
Procedure Update
Add Checks.Total to Vndr.Total_Paid
end_procedure
Procedure Backout
Subtract Checks.Total from Vndr.Total_Paid
end_procedure
Quando um novo registro gravado, a update (e no a backout) chamada. Quando
um registro excludo, a backout (e no a update) chamada. Quando um registro
editado, ambas so chamadas. possvel que a backout e update ajustem balanos de
pais diferentes durante uma edio. Isso pode acontecer se a edio fez com que o
registro pai fosse alterado. Os DDOs suportam isso.
Quase sempre o contedo de uma update ser o inverso da backout. Sempre que a
update fizer uma adio a um balano, a backout dever fazer uma subtrao. No
pense que a update e a backout s so enviadas durante uma gravao. Apesar disso
ser verdade nos casos onde os registros pais no so trocados, isso no ser verdade
quando os arquivos pais so trocados. O processo de manuteno da integridade
relacional quando os registros pais so trocados muito complicado e ambas as
procedures podem ser chamadas mltiplas vezes para o mesmo arquivo de dados (para
diferentes registros).
Se uma alterao em um registro tiver que ajustar balanos em ambos um registro pai e
um registro av (por exemplo, o check detail ajusta o checks total, que por si ajusta o
vendor total), melhor deixar um arquivo apenas para ajustar seus pais imediatos (por
exemplo, a update do check detail deve ajustar o checks file, e a update do checks deve
ajustar o vendor file).

44
U
s
a
n
d
o

D
D
O
s

Deleting
A deleting chamada durante o processo de excluso. Ela enviada antes da
mensagem backout.
Creating
A creating chamada quando um novo registro est sendo salvo. Essa procedure
aumentada internamente pelo comando define_auto_increment para atribuir chaves de
identificao nicas (como os nmeros do cliente) quando forem criados novos registros.
Outras Mensagens
As mensagens que so mais freqentemente aumentados foram listadas. So elas a
validate_save, validate_delete, update, backout, deleting, e a creating. As seguintes
mensagens esto disponveis para um controle mais avanado do dicionrio de dados.
Diferentemente de algumas das mensagens acima, a maioria dessas mensagens
executa uma funo padro. Por essa razo, se voc aument-las, deve ter certeza que
executou um forward send na mensagem para que esta retenha a funo padro.
Relate_main_file
A relate_main_file no faz nada como padro. Ela chamada depois que um relate
(posicionamento dos registros pais) normal tenha sido executado. um gancho que
permite que voc execute relates personalizados depois que seu registro principal tiver
sido encontrado e related. Se voc for procurar um registro adicional na
relate_main_file, voc deve notificar o DDO que voc encontrou esse novo registro.
Voc faz isso enviando a mensagem request_relate (se o registro foi encontrado). A
request_relate tambm executar um relate no registro encontrado.
Isso particularmente verdadeiro se o DDO estiver atualizando o DDO pai do registro
que voc tiver encontrado. O cdigo a seguir procura um registro pai e notifica um DDO
sobre a procura.
Procedure relate_main_file
forward send relate_main_file
local integer mustFind
if not status softFile move 1 to mustFind
else if vndr.soft_id ne softFile.soft_id move 1 to mustFind
if mustFind begin //relate para o softFile se necessrio
Clear SoftFile
Move Vndr.Soft_ID to SoftFile.Soft_Id

45
U
s
a
n
d
o

D
D
O
s

Find eq SoftFile.Soft_Id
end
If status softfile Send request_relate SoftFile.File_Number
else Send request_clear_file SoftFile.File_Number
end_procedure
Observe a otimizao dessa procedure. A procura no sof t Fi l e s executada se: (a) o
buffer de registro do sof t Fi l e estiver vazio; ou (b) o registro do buffer for o errado (os
valores relacionados no coincidirem).
IMPORTANTE: Recomendamos que voc otimize suas procuras dentro da
relate_main_file. Como os DDOs no tm nenhuma maneira de saber qual procedure
est sendo executada, eles no podem otimizar essas procuras. Sempre que um DDO
pensar que o registro com relate personalizado possa estar incorreto, ele enviar a
relate_main_file. Ela enviada muito freqentemente. Se voc no otimizar suas
procuras (um processo simples), voc pode estar reduzindo significativamente suas
operaes do banco de dados.
Saiba que a relate_main_file nem sempre est procurando o registro que se relaciona
com o registro atual. Quando os registros pais estiverem trocados, a relate_main_file
ser chamada durante o processo de gravao para encontrar um registro relacionado
com os registros antes e depois de serem trocados. Por isso, o current_record no
deve ser utilizado em procedures relate_main_file. S o recnum deve ser usado na
mesma. O new_current_record permite que voc rastreie as alteraes do
current_record.
New_current_record
Esta procedure pode ser vista como uma procedure ps-procura, visto que ela
chamada sempre que um registro encontrado (sempre que o current_record for
alterado). A new_current_record recebe dois parmetros inteiros: o nmero de registro
antigo e o novo. Atravs da anlise desses dois parmetros, voc pode dizer se o DDO
encontrou um registro ou se est criando um novo (o new_recnum zero). Voc no
pode utilizar essa procedure para alterar o current_record. Essa mensagem enviada
para notificar que haver uma alterao. Voc no pode abortar a alterao.
Provavelmente, o uso mais comum da new_current_record armazenar a condio do
arquivo de dados logo aps uma procura. Current_record uma propriedade do DDO
muito til. Se seu valor for zero, o registro novo, e se seu valor for diferente de zero, o
registro j existe.
A new_current_record enviada quando o registro atual estiver sendo alterado, com
duas excees: se um DDO passou a estar em uso e o registro estabelecido for zero, a

46
U
s
a
n
d
o

D
D
O
s

new_current_record ser chamada (registro antigo=0, novo registro =0). Depois de
uma gravao, a new_current_record chamada para todos os DDOs que
participaram da gravao, mesmo se o registro no tiver sido alterado. Se precisar testar
essa condio, voc pode verificar o operation_mode e ver se este est configurado
para mode_saving.
procedure new_current_record integer oldrec# integer newrec#
forward send new_current_record oldrec# newrec#
// Se no quisermos que ocorram gravaes de registros existentes.
if (operation_mode =mode_saving AND oldrec# =newrec#) begin
:
end
else ...
end_procedure
Attach_main_file
Attach_main_file executa um attach. chamada durante as operaes de gravao e
procura. Voc pode utilizar essa procedure para criar attaches adicionais, para cancelar
todos os attaches, ou para criar seus prprios attaches customizados. O exemplo a
seguir executa um attach normal, exceto que um dos attaches do campo ignorado.
Procedure attach_main_file
Local String TempVal
Move Vndr.Parent_Stat to TempVal // lembre desse valor
// o attach normal ir anexar dados de todos os arquivos pais,
// incluindo um attach no Vndr.Parent_Stat. Queremos ignorar esse
// attach
Forward send attach_main_file
Move TempVal to Vndr.Parent_State // desfaz esse attach
end_procedure
Observe que a attach_main_file e a relate_main_file no so o inverso uma da outra.
A relate_main_file no faz nada como padro (um relate ocorre como parte da
procura). A attach_main_file executa o comando attach.
Save_main_file, Clear_main_file, Delete_main_file
Por padro, essas mensagens gravam, limpam, ou excluem o arquivo principal.
Geralmente, voc ir executar um forward send nessas mensagens. Voc pode ento

47
U
s
a
n
d
o

D
D
O
s

gravar, excluir, ou limpar arquivos de forma personalizada. Se estiver limpando um
arquivo adicional, voc deve dizer ao DDO sobre o envio da mensagem
request_clear_file:
Procedure Clear_Main_File
Forward Send clear_main_file
Clear AuxFile
Send request_clear_file AuxFile.File_Number
end_procedure
Voc pode utilizar a save_main_file para marcar a hora/data de gravao em um
arquivo. Queremos que um registro fique marcado como alterado se houverem
alteraes no arquivo. Por esse motivo, iremos aumentar a procedure que executada
mais prxima da gravao. Se o buffer do arquivo for alterado, iremos marcar o registro.
Procedure save_main_file
// s marca o registro se este j tiver sido alterado. Isto assume,
// que as funes Crnt_Date e Crnt_Time j existem.
IfChange Vndr Begin // se o registro for alterado
Get Crnt_Date to Vndr.Date_Stamp
Get Crnt_Time to Vndr.Time_Stamp
End
// agora executamos o comportamento normal da gravao.
Forward Send save_main_file
end_procedure
Criando as Procedures / Funes Validate, Entry, & Exit
Voc pode especificar uma procedure ou funo para ser chamada sempre que o cursor
entrar ou sair de qualquer form ou coluna anexados a um campo, ou quando quiser
executar uma validao em um certo item. Elas funcionam da mesma forma que as
opes iEntry=, iExit=, e iValidate= aplicadas aos comandos da entry_item nos DEOs,
mas nos Dicionrios de Dados, elas se aplicam a todos os itens anexados ao campo
atravs.
Observao: Atualmente as mensagens Field_Entry e Field_exit no Dicionrios de
Dados no so usadas com aplicaes baseadas no WebApp porque a interface com o
usurio (isto , o browser) no tem como processar estas mensagens. Elas so usadas
somente no VDF e no DF caracter mode.

48
U
s
a
n
d
o

D
D
O
s

Voc especifica o nome da mensagem de entrada atravs da configurao da
propriedade field_entry_msg para cada campo, o nome da mensagem de sada atravs
da configurao da field_exit_msg, e o procedimento de validao atravs da
field_validate_msg. Voc deve configurar essas propriedades dentro da subclasse
DataDictionary na procedure define_fields. Voc tambm deve definir, nas subclasses,
as procedures ou funes identificadas nessas propriedades.
Essas mensagens podem ser procedures ou, se forem funes, voc deve codific-las
para retornar o valor 0 quando as condies forem satisfatrias, permitindo dessa forma
que a entrada, sada, ou outro evento de validao seja completada. Voc deve codific-
las para retornar um valor diferente de zero nas situaes onde voc queira que o
evento no seja permitido e presumivelmente alguma mensagem de erro ou semelhante.
Essa tcnica muito comum no caso das mensagens de validao.
A field_validate_msg o caso geral de validao no DataFlex, e no possui outra
definio alm da que voc codificar. Outras validaes mais especficas, discutidas em
outro lugar deste captulo, so fornecidas no DataFlex junto com definies
generalizadas. Essas validaes so as propriedades field_value_check,
field_value_range, e field_value_table. A field_check_values tambm possui
algumas funes de validao, que podem eliminar a necessidade da
field_validate_msg.
As validaes de uso especfico mencionadas acima esto acompanhadas por textos de
erro pr-definidos que explicam a natureza dos erros de entradas aos usurios em falhas
de validao, completando com parmetros para entrada vlida. Se voc utiliza uma
field_validate_msg personalizada, voc pode exibir os erros atravs da utilizao da
propriedade field_error. Essa propriedade, da mesma forma que as de uso especfico,
devem ser configuradas na procedure define_fields de sua subclasse DataDictionary.
Utilizando Tabelas de Validao
Se um campo precisar ser validado como sendo um de dois valores (Sim/No, etc.), um
conjunto limitado de valores, ou um intervalo de valores, voc pode utilizar um dos
mtodos de validao j detalhados (field_checkbox_values, field_value_check e
field_value_range). Em muitos casos, voc ver que esses tipos de validao so muito
limitados para suas necessidades. Nestes casos voc dever utilizar o tipo de validao
field_value_table. A utilizao de uma tabela de validao de campo possui as
seguintes vantagens: voc pode especificar um nmero maior de valores vlidos que
podem ser facilmente encaixados em uma string de verificao; voc pode especificar e
exibir uma descrio para cada valor de sua lista; voc pode manter seus valores da lista
dinamicamente (ou seja, os valores no tm de ser codificados em seu programa), e
pode optar por fazer desta lista uma lista de escolhas opcionais (ou seja, voc pode

49
U
s
a
n
d
o

D
D
O
s

exibir uma lista de valores sugeridos durante a entrada de dados, mas no necessrio
fazer uma seleo a partir da lista).
O conceito de uma tabela de validao simples. Voc deve criar um objeto de tabela
de validao em seu programa. Esse objeto , ento, atribudo aos campos dos
dicionrios de dados atravs da utilizao da mensagem field_value_table. Uma vez
atribudo, o campo utilizar esse objeto como uma validao e exibir o contedo dele.
Apesar do conceito e utilizao das tabelas de validao serem simples, seus benefcios
so considerveis. Como a validao e exibio so manipuladas por objetos especiais,
possvel manipular qualquer tipo de condio de validao de lista. De fato, voc pode
criar suas prprias subclasses de tabela de validao. Ela simplesmente um objeto
que contm uma lista de valores vlidos (e descries opcionais) que entendem um
protocolo pr-definido de mensagem para que os objetos de dicionrio de dados e de
entrada de dados possam se comunicar com ela.
Apesar de voc poder criar suas prprias subclasses personalizadas de validao,
provavelmente isso no ser necessrio. Fornecemos vrias classes de validao de
tabela que muito provavelmente iro satisfazer todas as suas necessidades.
Criando um Objeto ValidationTable
Um conjunto de exemplos simples deve fornecer toda a informao necessria para a
criao de seus prprios objetos validation table. Iremos iniciar este exemplo sem utilizar
tabelas de validao. Supomos que temos um objeto de entrada de dados definido de
uma das seguintes maneiras:
No Windows
Object Status_Entry is a dbForm
entry_item Customer.Status
End_Object
Ou
Object Status_entry is a dbComboForm
end_Object
Em Ambientes Character-Mode
Object Status_Entry is a Entry_form customer_status_img
Entry_Item
:

50
U
s
a
n
d
o

D
D
O
s

End_item_List
End_Object
Ou
Object Status_entry is a Radio_Entry_Form customer_status_img
end_Object
No iremos alterar nenhum desses objetos de entrada de dados. Iremos alterar os tipos
de validao utilizados pelo Campo Cust omer . st at us no dicionrio de dados. Ns no
comearemos usando uma tabela de validao. Ao invs disso, iremos atribuir ao
Cust omer . St at us a seguinte string de verificao:
Set Field_Value_Check field Customer.Status to O|C|D
// Open, Closed, flagged for Deletion
Atribuindo esse campo, teremos dois comportamentos:
Antes de gravar esse registro, o valor do Cust omer . St at us deve ser O, C, ou D.
Se um usurio pedir uma lista de valores vlidos, as opes O, C e D sero
apresentadas. A classe de entrada de dados utilizada determinar o tipo de lista
que ser apresentada. Se o DEO for um entry form simples, (entry_form ou
dbForm), uma lista popup aparecer quando um usurio selecionar um prompt.
Se o DEO for um combo form (dbComboForm), a lista combo drop-down ir
conter os valores vlidos. Se o DEO for um radio form (radio_entry_form), as
opes sero apresentadas como um radio list. Cada um desses DEOs sabe
como interagir com o dicionrio de dados de uma forma apropriada com suas
capacidades. Todo esse processo automtico.
Agora, iremos substituir a mensagem field_value_check por uma mensagem
field_value_table.
Set Field_Value_Table field Customer.Status to
(Status_Table(current_object))
Isso no suficiente para executar (ou at mesmo compilar). Agora, precisamos criar
um objeto que possa ser utilizado por esse campo. Faremos isso criando o objeto global
ValidationTable st at us_t abl e, acima da classe que o utiliza como a seguir:
Procedure Fill_List

51
U
s
a
n
d
o

D
D
O
s

end_Procedure
End_Object
:
Class Customer_DataDictionary is a DataDictionary
:
Set Field_Value_Table field Customer.Status to
(Status_Table(current_object))
:
Isso fornece exatamente a mesma funcionalidade que a field_value_check. Atualmente,
a nica vantagem de se utilizar uma tabela de validao que esse objeto pode ser
utilizado por outras views do dicionrio de dados que tambm necessitem de acesso aos
mesmos tipos de validao.
Alm disso, atravs da alterao de vrias propriedades, podemos fornecer algumas
capacidades de validao adicionais. Essas propriedades so allow_blank_state,
validate_state, e list_title.
Se a allow_blank_state for true, um valor vazio () tambm considerado como um
valor vlido. Agora, isso permitir que o valor do campo seja O, C, D ou nada
(presumidamente indefinido). Se voc estivesse utilizando um radio_entry_form,
provavelmente iria querer configurar a select_mode do form para single_select. Isso
permitiria que voc selecionasse um dos trs valores ou nenhum.
Se a validate_state estiver configurada para false, a validao no ser executada
nesse campo. Por qu iramos fazer isso? Algumas vezes queremos fornecer ao usurio
um conjunto de sugestes, mas no obrigatrias. Configurando validate_state para
false, voc ainda tem acesso s listas (listas popup, listas combo e radio), mas os
valores nas listas no so requeridos. Elas so sugestes.
A configurao de uma list_title fornece um ttulo personalizado que ser utilizado
quando uma prompt list popup for gerada para essa lista.
A outra vantagem da utilizao do objeto de validao que voc pode preencher sua
lista de vrias maneiras. Por exemplo, voc pode carregar suas opes para o objeto a
seguir com uma lista serial de opes delimitadas por linha.
Set Validate_State to False // Apenas sugestes

52
U
s
a
n
d
o

D
D
O
s

// ttulo para a prompt list de popup
Procedure Fill_List
Local String stat
Direct_Input Status.txt
If not (SeqEof) Begin
Readln stat
// l a primeira linha
While not (Seqeof)
Send Add_table_value Stat
Readln Stat
// l um valor do status
Loop
Close_Input
End
end_Procedure
End_Object
Criando uma Descrio para o Objeto ValidationTable
Baseando nossa tabela de validao na subclasse da ValidationTable fornecida,
DescriptionValidationTable, podemos oferecer uma descrio para cada item.
Object Status_Table is a DescriptionValidationTable
Procedure Fill_List
Send Add_table_value O Opened
Send Add_table_value C Closed
Send Add_table_value D Flagged for Deletion
end_Procedure
End_Object
O processo de validao e os dados que so lidos e escritos em seu banco de dados
permanecero inalterados. Seus DEOs manipularo essa tabela de um modo um pouco
diferente. Dependendo da classe do DEO, os dados sero apresentados em forma de
dados, descrio, ou como uma combinao dos dois. Seus entry forms e grids

53
U
s
a
n
d
o

D
D
O
s

(Entry_form, Grid, dbForm e dbGrid) sempre exibiro os valores dos dados atuais.
Uma prompt list apresentar a descrio, alm de exibir os dados normais, quando for
chamada a partir do DEO. Os objetos combo forms (dbComboForm) e radio entry
(Radio_entry_form) s exibiro a descrio. Com as prompt lists, combos e radios,
voc pode optar por exibir qualquer combinao de dados e descrio (voc
simplesmente altera uma propriedade no objeto de entrada). No entanto, voc perceber
que o modelo de exibir apenas a descrio o mtodo mais utilizado nas aplicaes.
Em entry forms character-mode (Entry_form) e em todos os grids (Grid e dbGrid),
possvel exibir a descrio ao lado dos dados. Isso ser descrito em uma seo
posterior. Voc ver que a caracterstica de exportao da descrio no suportada
pelo entry form do Windows. No Windows, a combo form fornece um mtodo melhor
para a utilizao dessa funcionalidade.
Utilizando um Arquivo do Banco de Dados para Fornecer Valores de
Validao
A classe FileValidationTable (uma subclasse da DescriptionValidationTable) facilita o
carregamento de seus dados e descries a partir de um arquivo DataFlex. Voc faz
isso atravs da configurao de propriedades para definir o datafile; os campos que
recebero os valores (o cdigo) e a descrio, e o ndice utilizado para carregar os
registros. O exemplo a seguir criar uma tabela de validao que ir carregar seus
dados a partir de um arquivo chamado Cust St at cujo primeiro campo contm o valor do
dado e o segundo contm a descrio. Todos os registros sero carregados utilizando o
ndice Nmero 1 do cust St at .
Set Code_Field to 1 // o cdigo est no campo 1
Set Description_field to 2 // a descrio est no campo 2
Set Ordering to 1 // carrega pelo ndice 1
End_Object
Atualmente, os valores padres do code_field, description_field e ordering so os
descritos acima, por isso esse objeto pode ser definido da seguinte maneira:
End_Object
Uma tabela de validao uma tabela batch-based. Todos os itens so carregados de
uma s vez. Por isso, espera-se que a lista de itens de qualquer tabela de validao seja
(razoavelmente) pequena e ser esttica (uma vez que a tabela estiver carregada, seu

54
U
s
a
n
d
o

D
D
O
s

contedo no ser alterado) durante qualquer seo em que estiver sendo utilizada. Se
voc tiver muitos itens ou se sua lista de itens for dinmica, voc precisar fazer
relacionamento entre os arquivos e dever utilizar as tcnicas de validao e lookups
relacionais.
Se sua lista de itens vlidos for pequena, mas voc quer que ela possa ser alterada
durante sua utilizao, pode-se criar uma tabela de validao que no esttica
configurando a propriedade static_state para false. Quando voc faz isso, a tabela
sempre preenchida antes de ser utilizada para a validao e a lista (combo list, prompt
list) preenchida sempre que for exibida. A criao de uma tabela que no esttica ir
aumentar o tempo de processamento, porque a tabela de validao atualizada
constantemente. Se o nmero de itens for muito pequeno, no haver diferena na
velocidade de processamento.
Outras propriedades chamadas type_field e type_value podem ser utilizadas para
carregar um conjunto de registros de um arquivo de dados. Quando elas forem
utilizadas, s os registros cujo valor do Campo type_field coincidir com o valor do
type_value sero carregados. Quando voc restringe os registros desta forma,
assegure-se que seu ndice de ordenamento est otimizado para haver um
carregamento rpido (o ndice deve ser composto do type_field + code_field).
Provavelmente, voc nunca precisar utilizar essas propriedades, porque a subclasse
CodeValidationTable fornece os meios e o arquivo para executar isso diretamente.
Utilizando um Arquivo Centralizado do Banco de Dados para Todas as
Validaes
Se voc utilizar um objeto CodeValidationTable, seus valores de validao sero
carregados a partir do arquivo CODEMAST. Esse arquivo contm um conjunto (ou tipos)
de valores de validao. Atravs da especificao do tipo, todos os cdigos e descries
para esse tipo ficam disponveis. Os dados desse arquivo podem ser mantidos atravs
da utilizao da view Code Maintenance.
End_Object
A tabela de cdigo a seguir definir uma tabela dinmica para todos os tipos de Status.
Os objetos exibidos recebero o ttulo Cust omer St at us Types, e a lista no ser utilizada
para validao.
Set List_title to Customer Status Types

55
U
s
a
n
d
o

D
D
O
s

Set Static_State to False
Set Validate_State to False
End_Object
importante observar que os DEOs (entry forms, combo forms, radio lists) no precisam
de alteraes para suportar qualquer uma das tabelas de validao acima. Esses DEOs
simplesmente pedem os dados e requerem os servios de validao do seu dicionrio
de dados. Eles no se importam como essa informao obtida. Isso torna as tabelas
de validao bastante flexveis e poderosas.
Exportando Descries de uma Tabela de Validao
Se voc quiser, voc pode criar entry forms e grids que permitam que voc insira um
valor (ou cdigo) em um item e exiba a descrio do cdigo como displayonly no item
seguinte. Isso suportado em objetos de entrada de dados multi-item (modo caractere:
Entry_form, Grid, Windows: dbGrid). Isto no suportado nos dbForms do Windows
porque eles so objetos simples e suportado nos dbComboForms. Essa tcnica pode
ser utilizada com qualquer tabela de validao que suporte os valores de cdigo e
descrio (DescriptionValidationTable, FileValidationTable, CodeValidationTable).
Para exportar descries, voc deve configurar uma propriedade do item para seu item
de cdigo (Set Export_Code_Description_State to True) e definir seu item de
exibio com uma expresso especial (entry_item
(Code_Description(Current_Object)). O item da descrio sempre deve ser o item
seguinte em relao ao item do cdigo.
Um form em modo caractere:
Object My_form is an Entry_form customer_image
:
Item_List
Entry_Item Customer.Name
Entry_Item Customer.Id
Entry_Item Customer.Status
Set Export_Code_Description_State to True
Entry_Item (Code_Description(Current_Object))
// define o item como um campo da descrio
Entry_Item Customer.Region
End_Item_List
:

56
U
s
a
n
d
o

D
D
O
s

End_Object
Um grid no Windows:
Object My_Table is a dbGrid Main_File Customer
:
Begin_row
Entry_Item Customer.Name
Entry_Item Customer.Id
Entry_Item Customer.Status
Set Export_Code_Description_State to True
Entry_Item (Code_Description(Current_Object))
Entry_Item Customer.Region
End_Row
:
End_Object
A Export_Code_Description pode ser codificada em qualquer um dos seguintes estilos:
Set Export_Code_Description item CURRENT to True
Set Export_Code_Description item (Current_Item(Current_Object)) to True
Set Export_Code_Description item 2 to True // somente se for o terceiro
item
Tabelas de Validao Globais vs. Dedicadas
Geralmente voc ir fazer um objeto de tabela de validao global. Isso torna o objeto
disponvel para qualquer dicionrio de dados que precisar da validao. Nesse caso, a
mesma lista de itens vlidos e descries estar disponvel para todos os dicionrios de
dados. Os objetos de validao globais devem ser posicionados fora da definio da
subclasse datadictionary. Voc pode criar um pacote para o objeto de validao e utiliz-
lo na sua subclasse datadictionary, ou pode definir o objeto imediatamente acima de sua
definio da subclasse:
End_Object

Class Customer_dataDictionary is a DataDictionary

57
U
s
a
n
d
o

D
D
O
s

:
Set Field_Value_Table field Customer.Status to ;
Ou tambm pode posicionar o objeto de validao em seu prprio arquivo package e
utiliz-lo:
Use StatVal.pkg // cria um objeto chamado Status_Table
:
No exemplo acima, o mesmo objeto fsico de validao est disponvel para todos os
objetos. Em alguns casos, voc pode querer criar um objeto para dicionrios de dados
especficos. Voc s ter que fazer isso se quiser que cada objeto de validao seja
diferente. Nesse caso, voc deve posicionar o objeto dentro da procedure define_fields.
Quando o objeto DataDictionary for criado, s uma instncia do objeto de validao
ser criada.
:
End_Object
:
Voc no deve posicionar esse objeto diretamente dentro da classe. O objeto de
validao deve ser inserido dentro de uma procedure ou funo (como a define_fields).
Como o objeto definido em uma procedure ou funo, voc no pode posicionar
procedures e funes dentro do objeto de validao. Se precisar faz-lo, voc deve criar
uma subclasse que contenha as procedures e funo e ento criar uma instncia dessa
subclasse.

58
U
s
a
n
d
o

D
D
O
s

Class Status_Table is a ValidationTable
Procedure Fill_List
:
end_Procedure
End_Class

:
Object Status_Table is a Status_Table
End_Object
:
Criando Suas Prprias Classes de Tabela de Validao
Provavelmente, as classes da validation-table fornecidas (ValidationTable,
DescriptionValidationTable, FileValidationTable, e CodeValidationTable) iro
manipular todas as suas necessidades em relao a tabelas de validao. Se no
satisfizerem, voc deve criar subclasses. Essas classes foram cuidadosamente criadas
para fornecer uma tima performance.
Se quiser, voc pode criar classes de validao personalizadas. Voc pode fazer com
que essas classes funcionem do jeito que voc quiser desde que elas suportem a
interface pr-definida. Quando uma tabela de validao atribuda a um campo em um
dicionrio de dados, o dicionrio e os DEOs que utilizam o campo esperam que essa
tabela de validao junte-se a uma interface especfica.
Uma tabela de validao deve suportar a seguinte interface pblica:

59
U
s
a
n
d
o

D
D
O
s

Get Static_State to St at e
Get Validate_State to St at e
Get Number_Elements to Val
Get Validate_Value dat a_val ue to St at e
Get List_title to Ti t l eVal ue
Send Request_Fill_From_List Obj ect I d MessageI d
Como voc pode ver, essa interface muito simples e abstrata. Ela nem especifica se
uma mensagem deve ser representada como uma funo ou propriedade. Isso no
relevante para a interface. Os mtodos atuais de processamento destas solicitaes so
internos e podem ser muito complicados. Desde que a interface se una, voc pode fazer
uma tabela de validao agir da maneira que quiser.
Get Static_State to State
Esta propriedade utilizada para especificar se as listas (listas de prompt popup, lista
combo drop-down, e listas radio) devem ser preenchidas cada fez que forem chamadas
pelo DEO. Geralmente, as tabelas de validao so estticas (esta propriedade
configurada para true). Geralmente ser usada como uma propriedade.
Get Validate_State to State
Esta propriedade especifica se a lista deve ser utilizada com propsito de validao. Se
for true, voc ter que definir a mensagem get validate_value. Geralmente ser usada
com o uma propriedade.
Get Validate_Value data_value to State
Se a get validate_State true, a mensagem validate_value ser enviada para o
objeto. Ela envia o data_value para ser validado. Se retornar um valor zero, o valor
vlido, e se retornar um valor diferente de zero, a validao falhou. O mtodo utilizado
para validar isso deixado inteiramente com a classe. Geralmente ser utilizada como
uma funo.
Get Number_Elements to value
Determina como vrios elementos so utilizados para representar um item de dados.
utilizada por objetos visuais (prompt lists, combo forms, radio forms) para determinar
como exibir os dados. Atualmente os valores 1 e 2 so suportados. 1 indica que apenas
o valor dos dados (cdigo) est disponvel, e 2 indica que ambos os valores dos dados e
descrio esto disponveis. Geralmente ser usada com o uma propriedade.

60
U
s
a
n
d
o

D
D
O
s

Get List_title to TitleValue
Os objetos podem requerer um ttulo para uma prompt list. Geralmente ser usada como
uma propriedade.
Send Request_Fill_From_List ObjectId MessageId
Esta mensagem executa uma tarefa muito especfica. utilizada quando outro objeto
(prompt list, combo form, etc.) precisar ser preenchido com valores vlidos. Quando esta
mensagem recebida, o objeto de validao deve enviar uma mensagem especificada
(MessageId) para um objeto especificado (ObjectId), passando a informao sobre cada
item da tabela de validao. A seguinte informao deve ser enviada de volta para o
ObjectId: Item number, Data value, Description value, File number, e Record Number. O
item number e o data value devem conter informaes. Se o Description value, File
number, ou Record number no existirem, voc deve enviar valores vazios (, 0, e 0),
mas cinco valores sempre devem ser passados como retorno.
Procedure Request_Fill_from_List integer ObjectId integer MessageId
Local integer numItms ItmCnt
Local string DataVal DescVal
Get Number_Values to numItems
// nmeros de itens na tabela de validao
Decrement numItems
For ItmCnt from 0 to numItems
get data_Value item ItmCnt to DataVal
get Description_Value item ItmCnt to DescVal
Send MessageId to ObjectId itmCnt DataVal DescVal 0 0
Loop
end_procedure
Este exemplo supe que sua classe da tabela de validao defina e entenda as
mensagens internas get number_values, get data_value, e get description_value.
O Buffer Local do Campo
Os dicionrios de dados mantm um buffer dos valores atuais de todos os campos do
arquivo de dados. Esse buffer separado e distinto do buffer de registro DataFlex. Ele
mantm o valor atual de cada campo como field_current_value e o estado de alterao
como field_changed_state. Esse valor sincronizado com quaisquer valores exibidos
utilizando o respectivo arquivo/campo. Essa sincronizao , na maioria das vezes,

61
U
s
a
n
d
o

D
D
O
s

automtica. Quando um registro encontrado, esse buffer local atualizado com o
contedo do buffer de registro do DataFlex, e todos os field_changed_states so
configurados para false. Quando um valor de entrada do item alterado, o dicionrio de
dados notificado sobre esta mudana e o valor do buffer local do campo e a
changed_state so atualizados. Alm disso, quaisquer outros itens de entrada que
utilizam o arquivo e o campo tambm sero atualizados. Quando um registro salvo,
apenas os valores alterados so movidos do buffer local do campo para o buffer de
registro do DataFlex.
Um programa pode alterar um valor do campo e/ou seu estado diretamente atravs da
configurao do field_current_value e field_changed_state (ou configurando o
field_changed_value). Quando isso ocorrer, todos os itens sero atualizados para
refletir a alterao. Apesar de voc poder configurar um valor de entrada do item
diretamente (que configurar a field_current_value), isso no recomendado. Da
mesma forma, voc pode acessar um valor do campo e no um valor do item (apesar de
ambos funcionarem).
O valor do campo no buffer local pode no ser o mesmo do valor do buffer do arquivo
(registro) DataFlex. Um buffer de arquivo (quando atual) mostrar o valor original do
campo conforme foi carregado do disco aps a procura. O field_current_value mostra o
valor atual do campo conforme a alterao feita pelo usurio ou pelo programa. Durante
uma gravao, o buffer de arquivo eventualmente atualizado com o valor do buffer
local do campo. Em procedures gancho de gravao e excluso (update, backout,
creating, deleting), voc deve utilizar os valores do buffer de arquivo e no do buffer
local do campo.
A Propriedade Current_record
Quando um DDO encontra um registro, ele posiciona o nmero do mesmo em uma
propriedade chamada current_record. Essa propriedade contm o registro com o qual o
DDO pensa que est trabalhando. Voc pode consultar a propriedade current_record
para descobrir se o DDO contm um registro. Se quiser que um DEO grave novos
registros e no possa editar registros existentes, voc deve aumentar a request_save
do DEO da seguinte forma.
// S permite gravao de registros novos.
// Este um pedido para gravao em um DEO, NO em um DDO
Procedure request_save
Local integer Srvr
Get Server to Srvr // quem meu servidor?
If (current_record(srvr) =0) Forward Send request_save

62
U
s
a
n
d
o

D
D
O
s

end_procedure
O DEO do exemplo acima precisava descobrir se seu DDO continha um registro. Todo
DEO possui uma propriedade chamada server que retorna o object ID do DDO que ele
utiliza. Neste exemplo, estamos procurando o object ID do DDO (o servidor) e depois
seu current_record. Voc precisa compreender esta tcnica. Ela utilizada toda hora.
Apesar de ser possvel ler a propriedade current_record diretamente, voc no pode
configur-la diretamente. Voc pode configur-la indiretamente atravs do envio de uma
das mensagens de procura.
As Mensagens de Procura
As principais mensagens de procura dos DDOs so a request_find, find_by_recnum e
request_assign. As mensagens de procura buscam um registro, executam um relate,
configuram as propriedades current_record apropriadas dos DEOs, notificam todos os
outros DDOs sobre o novo registro, e notificam todos os DEOs que esto conectados
estrutura do dicionrio de dados sobre o novo registro. esse processo de notificao
que faz com que os DEOs anexados estrutura de dicionrio de dados atuem de forma
coordenada.
Geralmente, voc no ter que aumentar as mensagens de procura. Esse aumento
considerado uma tcnica avanada. Voc ter que enviar mensagens de procura para
os DDOs. Isso ser discutido na prxima seo.
Request Assign
Se voc procurar um registro manualmente (com o find ou o comando
constrained_find) e quiser que o DDE entenda e exiba o registro atual, voc pode
enviar a mensagem request_assign. A request_assign ir fazer com que o DDO e
seus pais aceitem o registro do buffer como sendo seus registros atuais e atualizem
todos os DEOs afetados. A request_assign deve ser utilizada com cuidado. O DDO no
verifica se os registros que ele est aceitando esto relacionados. Porque esse processo
manual, de sua inteira responsabilidade assegurar que os registros do buffer esto
adequados. Antes de enviar a request_assign, voc deve assegurar que todos os
registros dos buffers esto adequados.
Muitas vezes, voc pode utilizar a request_assign e a find_by_recnum para o mesmo
propsito. Os dois exemplos a seguir daro o mesmo resultado.
clear myfile
move 17 to myfile.recnum
find eq myfile.recnum
relate myfile

63
U
s
a
n
d
o

D
D
O
s

send request_assign to (myfile_dd(current_object))
ou
send find_by_recnum to (myfile_dd(current_object)) myfile.File_number
17
Como os Objetos de Entrada de Dados Interagem com os
Dicionrios de Dados
A informao contida neste tpico aplica-se mais ao Visual DataFlex do que ao WebApp.
Contudo, esta informao includa para que voc possa ter uma idia melhor de como
os Objetos de Entrada de Dados interagem com os Dicionrios de Dados.
O objetivo dos pacotes de entrada de dados de alto nvel do DataFlex fazer com que a
interao entre os objetos de entrada de dados e seus dicionrios de dados seja
automtica. Por isso, no necessrio saber a informao fornecida nesta seo. Ela s
fornecida para quem quiser aumentar seu entendimento sobre o processo de interao
DEO - DDO.
Geralmente, esse processo envolve o redirecionamento de uma mensagem do item
para o dicionrio de dados. Um item de entrada ter as propriedades data_file e
data_field (que so configuradas pelo comando entry_item). Quando uma mensagem
do item precisar ser redirecionada, ela pergunta ao servidor (seu DDO) para encontrar o
arquivo e campo apropriado para esse item. O DDO do DEO procura o DDO apropriado
para o arquivo requerido (ele mesmo ou um DDO pai) e ento pede a informao
apropriada para o campo requerido. Todo o processo automtico, portanto o
conhecimento do mesmo no necessrio para a utilizao correta dos dicionrios de
dados.
As seguintes mensagens de item do DEO so redirecionadas da seguinte maneira:
Opes do Item Quando um DEO est conectado a seu dicionrio de dados,
as opes de campo do dicionrio so copiadas para os itens de entrada
apropriados. Nesse ponto, o dicionrio de dados determina se o item representa
um campo do arquivo principal ou estrangeiro. As opes apropriadas do campo
so copiadas.
Eventos de Entrada, Sada e Validao do Item Quando um item gerar
eventos de navegao ou validao, o DEO redirecionar essa mensagem para
o DDO apropriado. Dessa maneira, todos os eventos de entrada, sada e
validao do item, juntamente com as regras podem ser armazenadas no DDO.
Objetos de Prompt e Zoom Sempre que um objeto de prompt ou zoom for
solicitado (por exemplo, um usurio pressiona a tecla Prompt em um item de
entrada), o DEO redirecionar o pedido para o dicionrio de dados.

64
U
s
a
n
d
o

D
D
O
s

Status Help Sempre que o cursor entrar em um item, o status help solicitado
ao objeto de entrada. O pedido redirecionado para o dicionrio de dados.
O termo redirecionamento no completamente preciso. Todos os processos acima
foram aumentados para sustentar o suporte de campos do dicionrio de dados em
adio ao suporte de item regular fornecido. Se voc quiser, voc tambm pode
configurar as opes do item, mensagens do item, e os objetos do item diretamente nos
objetos de entrada de dados. Os efeitos das duas configuraes sero aditivos. Por
exemplo, voc pode criar uma mensagem de validao para o item (iValidate) em seu
DEO. Essa mensagem ser executada. Se no houver erro de validao, a mensagem
de validao do campo tambm ser enviada. Se voc adicionar item_options a um
item, ele ser utilizado junto com as opes de campo definidas no dicionrio de dados.
Essa natureza aditiva no enfatizada por que recomendado que voc posicione esse
tipo de cdigo em seus dicionrios de dados e o menos possvel nos DEOs. Essa
estratgia resulta na mxima reutilizao do cdigo.
Apesar de voc poder executar um get e set nos valores dos itens diretamente em um
DEO, recomendamos que voc faa isso atravs dos dicionrios de dados. Voc ver
que raramente ser necessrio acessar os valores do campo em seus objetos de
entrada de dados. A maior parte desse tipo de processamento ocorre dentro do
dicionrio de dados.
Quando precisar acessar essa informao, voc poder utilizar dois tipos de mensagens
que so definidas para fornec-la. Se precisar, voc pode encontrar o dicionrio de
dados que controla a informao necessria e ento enviar um get/set
field_current_value para o mesmo. Isso d muito trabalho existem mtodos mais
fceis.
As Mensagens File_Field e Item_Field do DEO
Se voc souber o arquivo de dados e os nmeros de campo do dado que voc precisa
acessar, utilize as mensagens file_field_. As mensagens file_field_ a seguir so
suportadas em objetos de entrada de dados.
get / set file_field_current_value
get / set file_field_select_state
get / set file_field_changed_state
Ambos o arquivo e o campo devem ser identificados. Isso pode ser feito enviando ambos
os valores ou utilizando a clusula file_field.
get_fieldnumber customer.name to myfield
move customer.file_number to myfile
get file_field_current_value myfile myfield to myvar

65
U
s
a
n
d
o

D
D
O
s

O mesmo pode ser feito da seguinte forma:
get file_field_current_value file_field customer.name to myvar
Quando voc configura o valor ou o estado de seleo, todos os itens de entrada de
dados da estrutura da view que esto conectados a esse campo sero atualizados.
Se voc souber o nmero do item ao invs do nmero do campo, voc pode acessar
uma propriedade do campo utilizando uma mensagem item_field. As seguintes
mensagens so suportadas:
get / set item_field_current_value
get / set item_field_select_state
get / set item_field_changed_state
Exemplo:
get item_field_current_value item 7 to myvar
Estas mensagens so utilizadas extensivamente pelas classes de entrada de dados.
Voc nunca precisar utiliz-las.
Construindo Estruturas de Dicionrio de Dados
Geralmente, um programa contm vrios DEOs. Alguns destes objetos agem de uma
forma coordenada com os outros objetos. Quando um registro encontrado exibido em
um objeto, ele tambm deve ser exibido em outros objetos. Outros DEOs devem ser
independentes. As alteraes feitas nesses DEO no devem afetar os outros. O DDO
o objeto que coordena as atividades entre os DEOs. Todos os DEOs que esto
conectados ao mesmo DDO agiro de uma forma coordenada.
Os DDOs tambm precisar agir coordenadamente com os outros DDOs. Fazemos isso
conectando os DDOs. Um grupo de DDOs interconectados recebe o nome de estrutura
de dicionrio de dados. Cada DDO em uma estrutura podem ter um ou mais DEOs
conectados a ele. Todos esses DEOs sero coordenados. Uma operao de gravao,
excluso, procura, ou limpeza em um DDO afetar todos os DEOs conectados
estrutura de dicionrio de dados de uma forma coordenada e inteligente.
Isso nos conduz para a regra mais importante dos DDOs:
Um DDO oferece servios coordenados de banco de dados para todo objeto de entrada
de dados que o utiliza e para todos os outros DDOs em sua estrutura de dicionrio de
dados.
A declarao acima o segredo da vida do universo DDO. Se voc quiser que um DEO
atue coordenadamente com outro DEO, voc deve se assegurar que ambos os DEOs
utilizam a mesma estrutura de dicionrio do dados. Da mesma forma, se voc no quiser

66
U
s
a
n
d
o

D
D
O
s

que um DEO aja coordenadamente com outro DEO, assegure-se que ele no est
utilizando a mesma estrutura de dicionrio de dados.
Uma view um objeto que contm uma estrutura de dicionrio de dados junto com
todos os DEOs que utilizam essa estrutura. Todos esses DEOs agiro de forma
coordenada. Essa coordenao no vem como resultado do fato desses objetos
residirem na mesma view. A coordenao ocorre se, e somente se, a estrutura de
dicionrio de dados estiver interconectada apropriadamente e se cada DEO estiver
conectado ao DDO apropriado. O objeto view simplesmente oculta essa complexidade
do mundo exterior.
Os DDOs so conectados com a mensagem set ddo_server. Os DDOs filhos se
conectam com os pais. Como uma regra geral, os vnculos de atualizao de arquivo
filho-para-pai estaro compatveis com os relacionamentos filho-para-pai que voc criou
no Database Builder. Iremos utilizar a seguinte estrutura de arquivo de dados como um
exemplo:

A B C
\ / /
D E
\ /
F
/ \
G H
Nesse diagrama, os arquivos pai esto acima e os filhos abaixo. Os arquivo G e H se
relacionam com o arquivo F. O arquivo F se relaciona com ambos os Arquivos D e E. O
arquivo D se relaciona com o A e o B. O arquivo E se relaciona com o Arquivo C. Os
arquivos A, B e C no possuem pais.
A criao da estrutura de dicionrio de dados para esses arquivos muito simples.
Primeiro crie os DDOs pais. Comece do topo e trabalhe da esquerda para a direita.
Todas as conexes sero manipuladas por um vnculo de atualizao (set ddo_server).
O exemplo a seguir mostra como o diagrama do arquivo criado em uma estrutura de
dicionrio de dados. O primeiro passo foi criar uma subclasse data-dictionary para cada
arquivo. Essas classes contm todas as regras de banco de dados necessrias para os
arquivos.

67
U
s
a
n
d
o

D
D
O
s

Object A_DD is a A_DataDictionary
end_object
Object B_DD is a B_DataDictionary
end_object
Object C_DD is a C_DataDictionary
end_object
Object D_DD is a D_DataDictionary
set ddo_server to (A_DD(current_object))
set ddo_server to (B_DD(current_object))
end_object
Object E_DD is a E_DataDictionary
set ddo_server to (C_DD(current_object))
end_object
Object F_DS is a F_DataDictionary
set ddo_server to (D_DD(current_object))
set ddo_server to (E_DD(current_object))
end_object
Object G_DS is a G_DataDictionary
set ddo_server to (F_DD(current_object))
end_object
Object H_DS is a H_DataDictionary
set ddo_server to (F_DD(current_object))
end_object
Tendo criado sua estrutura de dicionrio de dados, seus DEOs devem ser conectados
aos DDOs apropriados. A propriedade server utilizada para isso. Para saber onde em
uma estrutura de dicionrio de dados um DEO deve ser conectado, voc deve entender
como os DDOs e os DEOs interagem.
Quando um DEO for conectado a um DDO, o DDO referido como o servidor do DEO.
Um DEO no pode executar nenhuma atividade em um arquivo de dados sozinho. Ao
invs disso, ele envia uma mensagem para seu servidor para executar a funo. Um
DEO ir pedir a um DDO para gravar, excluir, limpar, ou procurar um registro. Quando
um DDO executar uma dessas operaes, ele ir interagir conforme o necessrio com
todos os outros DDOs nessa estrutura. Esses DDOs iro interagir seqencialmente com
todos os DEOs que estiverem conectados a eles. Um DDO envia duas mensagens para

68
U
s
a
n
d
o

D
D
O
s

um DEO. Ou ele ir pedir para o DEO mover os dados do objeto para o buffer do arquivo
de dados (entry_update), ou para mover os dados do buffer do arquivo de dados para o
objeto (refresh).
Propagao das Operaes do Dicionrio de Dados
Os DDOs executam as seguintes operaes: gravar, excluir, limpar, limpar tudo, e
procurar. Geralmente, essas operaes so iniciadas por um DEO que envia uma
mensagem para seu DDO servidor. Freqentemente, a operao do DEO iniciada
pelos usurios que pressionam uma tecla. Por exemplo, um usurio pode pressionar a
tecla F2, o que far com que a mensagem request_save seja enviada para o DEO. O
DEO enviar a mensagem para seu DDO, que tambm a request_save. Ento, o
DDO executar a gravao. Se voc compreender como as cinco principais operaes
do dicionrio de dados se comportam, voc poder prever como seu programa ir se
comportar.
Saves - Request_Save
Quando um DDO receber uma mensagem request_save, tentar gravar um registro em
seu arquivo principal. As gravaes se propagam para cima. Isso significa que uma
gravao pode afetar o arquivo principal de seu DDO e todos os DDOs acima dele na
cadeia de atualizao. Por exemplo, se a request_save for enviada para o Objeto A_DD,
um registro do Arquivo A ser salvo. Se a request_save for enviada para o Objeto D_DD,
os Arquivos D, A, e B sero salvos. Se a request_save for enviada para o Objeto F_DD,
os Arquivos F, D, E, A, B, e C sero salvos. Quais arquivos deveriam ser gravados se a
request_save for enviada para o H_DD? Se voc respondeu, que todos seriam gravados
menos o G, acertou. Isso significa que voc deve ter os DDOs dos arquivos pais
conectados apropriadamente se voc quiser que uma gravao do dicionrio de dados
seja processada corretamente.
No faz nenhuma diferena em qual item o cursor est quando o usurio solicitar a
gravao em um DEO. O registro que ser gravado determinado pelo DDO. Se, por
exemplo, o usurio pressionar F2 quando estiver em um campo vendor em um entry form
que estiver conectado a um DDO do checks, um registro checks ser gravado. Desta
forma, seu registro pai, o vendor , tambm ser gravado (isso supondo que sua estrutura
de dicionrio de dados esteja correta). Se o entry form estivesse conectado a um DDO
do vendor , a gravao ira ocorrer apenas no registro vendor , e no no checks.
Deletes - Request_Delete
Uma request_delete tenta excluir um registro do arquivo principal do DDO. Se a
propriedade cascade_delete_state for true, existirem DDOs filhos na estrutura de
dicionrio de dados, e existir um relacionamento entre os arquivos pais e filhos na

69
U
s
a
n
d
o

D
D
O
s

definio do arquivo, o DDO tambm excluir os registros filhos. Esse processo caminha
recursivamente para baixo na estrutura de dicionrio de dados. Apesar de uma
request_delete no poder excluir um registro do arquivo pai, ela pode atualizar um
arquivo pai. Isso significa que uma request_delete ser propagada para cima e para
baixo numa estrutura de dicionrio de dados.
Se a propriedade cascade_delete_state do DDO for false, o DDO no excluir um
registro que tiver registros filhos relacionados. Por isso, se houver uma excluso, a
direo de propagao s ser para cima (da mesma forma que a gravao).
Se uma request_delete fosse enviada para o Objeto H_DD, o registro do Arquivo H seria
excludo e os Arquivos A, B, C, D, E, e F seriam atualizados. Uma request_delete
enviada para o Objeto A_DD (se a cascade_delete_state for true) iria excluir um registro
no A, todos os registros filhos do A que esto no D, todos os registros filhos do D que
esto no F, e todos os registros filhos do F que esto no G e H. As excluses se
propagam para cima e para baixo na estrutura de dicionrio de dados. Os registros
excludos do D faro com que o Arquivo B seja atualizado, os registros excludos do F
faro com que os arquivos E e C sejam atualizados. Em outras palavras, todos os
DDOs da estrutura de arquivos seria afetado se houvesse uma excluso em A.
Isso sugere que voc deve ter uma estrutura de dicionrio de dados completa para
poder excluir registros em um arquivo pai. Isto verdade se voc quiser efetuar
excluses automticas dos registros nos arquivos filhos. Freqentemente, voc ir
querer proibir excluses se houverem registros no arquivo filho relacionados com o
registro do arquivo principal. Voc pode utilizar a propriedade cascade_delete_state
para fazer isso. Se voc no quiser que os registros que possuam filhos sejam
excludos, as excluses agiro da mesma forma que a gravao e s se propagaro
para cima na estrutura de dicionrio de dados.
Isso determinar o quo completa sua estrutura precisa estar representada dentro de
uma view. Se voc precisar que uma view possa gravar e excluir registros do Arquivo A
(poderia ser um arquivo de fornecedores) e estiver impedindo excluses se houverem
registros filhos, o nico DDO que ser necessrio na sua view o A_DD. Se voc quiser
excluir todos os registros filhos, voc precisar da estrutura de dicionrio de dados
completa.
Algumas coisas sobre as excluses devem ser enfatizadas. O arquivo cujo registro
excludo determinado pelo DDO e no pelo DEO que enviou a mensagem. O registro
ser excludo do arquivo principal do DDO que recebeu a mensagem. A propagao das
excluses para os registros filhos determinada pela estrutura de atualizao do
servidor de dados e pelos relacionamentos nas definies dos arquivos. Se algum dos
itens estiver incompleto, as excluses dos filhos no ocorrero. As restries no fazem
efeito nesse processo, mas a cascade_delete_state a lista de subclasses DD dos
arquivos filhos (mensagem add_client_file) fazem.

70
U
s
a
n
d
o

D
D
O
s

Clear e Clear_all
A mensagem clear_all simples. Ela limpa os arquivos da estrutura de dicionrio de
dados. A clear_all se propaga para cima e para baixo.
A mensagem clear limpa o main_file do DDO e ento se propaga para cima da
estrutura do servidor de dados. A clear no se propaga para baixo. Se uma clear for
enviada para o D_DD, os Arquivos D, A, e B seria limpos. Os outros arquivos no seriam
afetados.
Procurando
As principais mensagens de procura so a request_find, find_by_recnum, e a
request_assign. Essas mensagens so diferentes das outras mensagens, pois voc
pode pedir uma procura em um arquivo que no o principal do DDO. Por exemplo:
voc pode enviar a request_find para o D_DD pedindo para ele encontrar um registro no
Arquivo A. O DDO ir executar a procura e ento notificar o DDO apropriado (A_DD)
sobre os resultados. importante entender esta parte. Operacionalmente, o pedido de
uma procura em um DDO do arquivo filho o mesmo que pedir a procura diretamente
ao DDO do arquivo pai. Depois da procura, o DDO do arquivo pai configurar sua
propriedade current_record para o registro correto.
A procura executada pelo DDO que recebe a mensagem e no pelo DDO que possui o
arquivo procurado. Depois de uma procura, o DDO notificar os outros DDOs de sua
estrutura sobre o novo registro. Existem algumas implicaes interessantes para uma
utilizao avanada. Atravs do aumento dos procedimentos de procura nos DDOs,
voc pode fazer dois DDOs responderem diferentemente em relao procura do
mesmo registro. Por exemplo: podemos aumentar a mensagem request_find para o
DDO D_DD da seguinte forma:
Procedure request_find Integer mode Integer File# Integer Indx
If File# ne A.File_number forward send request_find mode File# Indx
end_procedure
Neste exemplo, desabilitamos procuras de registros do Arquivo A pelo DDO D_DD. As
mensagens request_find do Arquivo A que so enviadas para o D_DD so ignoradas.
Todas as outras procuras so processadas, e uma procura enviada diretamente para o
A_DD tambm deve ser processada.
Geralmente, uma operao de procura resultar na procura de registros pais (o processo
de relate). Quando isso acontece, os DDOs do arquivo pai so notificados
apropriadamente sobre o novo registro. Geralmente, um DDO procura por um registro
em seu arquivo principal ou em um de seus arquivos pais.

71
U
s
a
n
d
o

D
D
O
s

A propriedade current_record do DDO determina com qual registro o DDO ir trabalhar.
Algumas vezes o current_record do DDO e o registro do buffer de arquivo sero
diferentes. Os DDOs agem no current_record e no no contedo do buffer de arquivo
(na prtica ele assegura que o buffer est carregado com o registro correto antes de
uma gravao ou excluso). Uma simples procura de um registro no faz o DDO
armazenar o registro. Voc deve enviar uma das mensagens de procura para o DDO.
Isso configurar a propriedade current_record.
Utilize a mensagem request_assign se quiser que um DDO acesse o registro do buffer
de arquivo. Ela executar um relate no registro, notificar todos os DDOs envolvidos, e
enviar a mensagem refresh para todos os DEOs que sero afetados por esse
processo.
Utilize a mensagem find_by_recnum se voc quiser quem um DDO procure um registro
particular. Esta ir procurar o registro, executar um relate, notificar todos os DDOs
envolvidos, e enviar mensagem refresh para todos os DEOs que sero afetados por
esse processo.
A mensagem request_find ir procurar um registro de um arquivo selecionado, em uma
direo selecionada, atravs de um ndice selecionado. Ela tambm executa um relate,
notifica os outros DDOs, e atualiza os DEOs.
Quando essas mensagens so utilizadas, geralmente so enviadas a partir de um DEO.
Abaixo esto alguns exemplos de suas utilizaes.
// procedure dentro de um DEO
Procedure Do_Something
Local Integer Srvr# Rec# File#
Get Server to Srvr# // ID of DDO
:
// l o registro do buffer de arquivo do vendor
Send request_assign to Srvr# Vndr.File_Number
:
// ou, procura um particular para o main_file
Get Main_File to File#
Get My_Rec# to Rec# // propriedade definida pelo usurio
send find_by_recnum to srvr# File# Rec#
:
// ou, procura ou prximo registro do vndr pelo index.1
send request_find to srvr# GT Vndr.File_Number 1

72
U
s
a
n
d
o

D
D
O
s

:
End_Procedure
A compreenso de como os comportamentos do dicionrio de dados se propagam
muito til. Quando souber isso, voc poder prever como os DDOs se comportaro em
qualquer operao. Isso tambm ajudar voc a determinar onde os DEOs devem ser
conectados a uma estrutura de dicionrio de dados.
Um Exerccio de Propagao do Dicionrio de Dados
Exerccio 1
Possumos uma estrutura de dicionrio de dados (sem constraints) como mostra o
diagrama. Nossos DEOs podem se conectar a qualquer um desse objetos. Por exemplo,
se nosso DEO estivesse utilizando o DDO D, todos os pedidos de arquivo de dados do
DEO (gravao, limpeza, excluso, procura) sero manipulados pelo DDO D.
A B C
\ / /
D E
\ /
F
Clear All: O que acontecer se a clear_all for enviada para qualquer um dos DDOs?
[Todos os DDOs sero limpos].
Clear: O que acontecer se a clear for enviada para A? [A ser limpo] O que
acontecer se a clear for enviada para D? [D, A, e B sero limpos] O que
acontecer se a clear for enviada para F? [F, D, A, B, E, e C sero limpos] As
limpezas se propagam para cima.
Save: O que acontecer se uma request_save for enviada para A? [A ser salvo] O
que acontecer se uma request_save for enviada para D? [D, A, e B sero
salvos] O que acontecer se a request_save for enviada para F? [F, D, A, B, E, e
C sero salvos]. As gravaes se propagam para cima.
Delete: (Cascade_delete_state true em todos os DDOs.) O que acontecer se a
request_delete for enviada para A? [O A ser excludo, os filhos de A que esto
em D sero excludos, os filhos de D que esto em F sero excludos. B, E e C
sero atualizados]. O que acontecer se a request_delete for enviada para D?
[D ser excludo, os filhos de D que esto no F sero excludos. A, B, E e C

73
U
s
a
n
d
o

D
D
O
s

sero atualizados]. O que acontecer se a request_delete for enviada para F? [O
F ser excludo, e A, B, C, D, e E sero atualizados].
Find: Quando um pedido de procura feito a um DDO, o arquivo a ser encontrado
enviado como um parmetro. Voc pode pedir que o DDO procure um registro
de seu arquivo ou de qualquer arquivo pai. A no ser que voc tenha aumentado
suas procedures de procura, o pedido para o DDO A ou D para procurar um
registro do Arquivo A ter o mesmo resultado.
O que acontecer se uma request_find para o Arquivo A for enviada para A? [A ser
encontrado.] O que acontecer se uma request_find para o Arquivo A for
enviada para D ou F? [A ser encontrado]. O que acontecer se a request_find
para o Arquivo D for enviada para o D? [D ser encontrado, executado um
relate, e A e B sero notificados em relao aos novos registro relacionados]. O
que acontecer se uma request_find para o Arquivo F for enviada para o F? [F
encontrado, executado um relate, e o A, B, C, D e E sero notificados em
relao aos novos registros relacionados].
Exerccio 2
Daremos os seguintes valores nossa estrutura de dicionrio de dados:
A B C A = Customer
\ / / B = Terms
D E C = Vendor
\ / D = Order Header
F E = Inventory
F = Order Detail
F tem um constraint relates-to para D.
DEO_Header_Entry est usando D.
DEO_Table_Entry est usando F.
Agora possumos uma estrutura padro de arquivo de pedido. Iremos inserir dois DEOs
a essa estrutura: um order-header-entry form que utiliza D e um order-detail grid que
utiliza F. Isso significa que os usurios s enviaro as solicitaes de dicionrio de
dados para os DDOs D e F. Sem um constraint relates to entre F e D, os
comportamentos de entrada de dados no seriam apropriados para a nossa
configurao entry-form/grid. Os comportamentos de gravao e excluso esto
corretos; os comportamentos de limpeza e procura no.

74
U
s
a
n
d
o

D
D
O
s

Devemos adicionar um constraint relates to no DDO F que restringir os registros F em
qualquer momento a registros que se relacionem com o registro atual de seu arquivo pai
D. As restries no tm impacto sobre as gravaes ou excluses (o que bom). Elas
alteram os comportamentos de limpeza e procura (o que tambm bom).
Clear: O que acontecer se um clear for enviado para D? [D, A, e B sero limpos, D
notificar seu filho restringido, F, que ele possui um novo registro vazio. O F
tentar procurar um registro que est relacionado com o filho vazio.
Provavelmente ele falhar, limpando, com isso, F, E, e C. O resultado que
todos os arquivo sero limpos.] O que acontecer se um clear for enviado para
F? [F, E e C sero limpos. Quando F tentar limpar o DDO D, ele ir se deparar
com a restrio relates to e interromper a limpeza desse ramo.]
Find: O que acontecer se uma request_find para o Arquivo A for enviada para D
ou F? [A ser encontrado, e nada mais ser alterado]. O que acontecer se uma
request_find para o Arquivo D for enviada para D? [D ser encontrado e um
relate executado. A e B sero notificados em relao aos novos registros.
Alm disso, D notificar seu arquivo filho restringido, F, sobre o novo registro
pai. F ir procurar o primeiro registro vlido e dir ao objeto grid sobre o registro.
O objeto grid ir preencher o grid com registros vlidos. Os arquivo E e C
sofrero um relate e seus DDOs sero notificados sobre a alterao. Por isso,
quando D alterado, o registro filho do grid tambm ser alterado. Isso bom.]
O que acontecer se uma request_find para o Arquivo F for enviada para F? [o
F s ser encontrado se F for um filho vlido de D. Ento, D, A, e B no podem
ser alterados. Os Arquivos E e C sofrero um Relate e seus DDOs sero
notificados sobre a alterao.]
O objeto header conter os campos permitindo que procuremos os registros do
customer (A). Optamos por no restringir o arquivo order header ao arquivo
customer. Para objetivos de procura, no queremos que nossa procura por
pedidos esteja limitada a um nico cliente. No criamos um DEO separado para
os campos do cust omer . Se tivssemos feito isso (e esse DEO estivesse
utilizando o DDO do cust omer ), iramos ter como resultado comportamentos de
gravao e excluso indesejados. A gravao s iria gravar o arquivo cust omer .
As excluses iriam excluir o registro do cust omer e todos os seus filhos.
Exerccio 3
Agora iremos criar uma view para a entrada de clientes (customers). Iremos basear essa
view em um nico DDO.
A A = Customer
1. Quais seriam as complicaes se removssemos os DDOs dos

75
U
s
a
n
d
o

D
D
O
s

arquivos filhos? Se revisarmos nossas regras de propagao do
dicionrio de dados, observaremos que apenas a excluso se propaga
para baixo. As gravaes se propagam para cima. Se os DDOs dos
arquivos filhos no forem fornecidos, uma excluso no excluir os
registros filhos. Isso significa que iramos ficar com registros (pedidos)
rfos. Normalmente ns no queremos que isso acontea.
Controlaremos isso com a propriedade cascade_delete_state do DDO,
tornando impossvel excluir os clientes que possuam registros filhos.
2. Quo completa sua estrutura de dicionrio de dados deve ser?
Localize o DDO do arquivo mais abaixo na rvore, o qual ter um DEO
utilizando-o. Tenha certeza que todos os DDOs dos arquivos pais
esto em sua estrutura e se esto apropriadamente conectados. Se
no, suas gravaes e excluses podem no funcionaro
corretamente. Se no permitir excluses de registros que possuam
filhos, voc no precisar criar nenhum DDO abaixo do DDO mais
abaixo utilizado. Se permitir excluses de registros filhos, voc deve
ter certeza que os DDOs filhos e todos os DDOs atualizados esto
presentes e conectados.
Estrutura de Arquivo em forma de Diamante
As estruturas do dicionrio de dados podem suportar relacionamentos em forma de
diamante. Um relacionamento diamante aquele cujo arquivo pai pode ser alcanado
por um arquivo filho por mais de um caminho. Considere o seguinte exemplo:
A B C
\ / \ /
D E
\ / \
F I
/ \ /
G H
Neste exemplo, existem dois relacionamentos em forma de diamante (os Arquivos B e E
so o topo de cada diamante). Quando o Arquivo F procura um registro, existem dois
caminhos que ele pode utilizar para encontrar o pai relacionado no arquivo B ( F>D
>B ou F>E>B). Este tipo de estrutura suportada, desde que os relacionamentos
estejam apropriados. Se o Registro B puder ser alcanado por dois caminhos, voc

76
U
s
a
n
d
o

D
D
O
s

precisa ter certeza que esse registro que ser encontrado em B, ser o mesmo em
ambos os caminhos. Em outras palavras, os registros em D e E devem possuir o mesmo
pai em B. Similarmente, os registros em F e I devem ter os mesmo pais em E. Desde
que essas regras sejam obedecidas, os diamantes so completamente suportados. A
estrutura de atualizao de seus dicionrios de dados deve refletir a estrutura de
diamante. A redundncia em vnculos de atualizao no causar problemas; os DDOs
otimizam essa redundncia.
Resumo
importante que voc entenda como as operaes do dicionrio de dados se
comportam e propagam. Se entender isso, voc pode prever corretamente como suas
views iro se comportar. Abaixo est um resumo das operaes do dicionrio de dados
e seus comportamentos.
Operao do Dicionrio
de Dados
Comportamento Normal Comportamento com
Constraints
clear_all Limpa todos os DDOs
conectados
Idem
clear Limpa o DDO e todos os DDOs
que so atualizados. Propaga-
se para cima.
Limpa o DDO e todos os DDOs
que so atualizados a no ser
que uma restrio relates-to seja
encontrada. A limpeza nesse
ramo ser interrompida. Os
DDOs filhos com a restrio
relates-to sero notificados sobre
o novo registro vazio. Ele ir
limpar ou procurar conforme
necessrio.
request_save Grava o registro do DDO e
atualiza todos os DDOs pais.
Propaga-se para cima.
Idem
request_delete Exclui o registro do DDO e
atualiza todos os DDOs dos
arquivos pai. Os registros filhos
so excludos se seus DDOs
esto conectados e se a
cascade_delete_state for true.
Propaga-se para cima e
(condicionalmente) para baixo.
Idem
Finding Procura o registro do arquivo
solicitado. executado um
Se o DDO do arquivo possuir
uma restrio relates-to, apenas

77
U
s
a
n
d
o

D
D
O
s

Operao do Dicionrio
de Dados
Comportamento Normal Comportamento com
Constraints
relate. Todos os DDOs so
notificados sobre a alterao,
configurando a current_record
do DDO conforme o necessrio.
Qualquer DEO que utiliza
qualquer DDO afetado
atualizado.
os registros que satisfizerem os
requerimentos da restrio sero
encontrados. Os DDOs filhos
com a restrio relates-to sero
notificados sobre o novo registro.
Ele ser limpo ou procurado
conforme o necessrio.
Conectando mais que Um DDO ao Mesmo Arquivo
Espera-se que suas aplicaes contenham vrias views e que algumas dessas views
precisem utilizar o mesmo arquivo de dados. Cada view ter seu prprio DDO
encapsulado dentro dela. Cada um desses DDOs possuem o mesmo arquivo principal, a
mesma subclasse data-dictionary, e provavelmente tero at o mesmo nome. Alm
disso, todos esses objetos dividem o mesmo buffer de arquivo. Desde que voc no
tente colocar dois DDOs baseados no arquivo na mesma view, voc no ter nenhum
problema.
As operaes crticas do banco de dados so a gravao e excluso. Essas operaes
so seguras. Um DDO ir assegurar se possui os dados corretos em seu buffer de
arquivo antes de perseguir. Tudo isso automtico. Isso significa que os buffers estaro
corretos quando a maioria das mensagens do dicionrio de dados for processada
(update, backout, deleting, validate_save, validate_delete, etc.). Os DDOs notificam
os DEOs que eles precisam para exibir os dados atravs do envio da mensagem refresh
para os mesmos. Os buffers dos arquivos de dados esto corretos durante o processo
de refresh.
Existem ocasies que no se deve confiar nos buffers do arquivo de dados. Durante a
entrada de dados, possvel que o buffer do arquivo no contenha os dados que voc
pensa que ele contm. Se um usurio mudar de views durante um processo, possvel
que o registro com o qual o DDO pensa que est trabalhando (que identificado na
propriedade current_record do DDO) no seja o registro que est no buffer. Isso no
atrapalha o DDO, mas pode criar complicaes para voc, se seu cdigo do DEO for
baseado no contedo do buffer do arquivo. Existem vrias maneiras de contornar o fato
destes buffers de arquivos no serem verdadeiros.
Sempre que possvel, utilize o valor do objeto ao invs do valor do
campo do banco de dados com o qual o objeto est conectado.
Quando voc precisar tratar um valor que no estiver armazenado em
um objeto, voc ter que utilizar o buffer do arquivo. Antes de utilizar o
buffer, voc deve enviar uma mensagem para o DDO dizendo para ele

78
U
s
a
n
d
o

D
D
O
s

assegurar que o buffer est correto. Essa mensagem a
refind_records.
O mtodo padro de envio dessa mensagem :
Send refind_records to (server(current_object))
Por exemplo, podemos ter uma procedure field_entry_msg que carregue um form com
um nmero de carto de crdito padro. A propriedade configurando a procedure de
entrada est descrita abaixo:
field_entry_msg item 0 dflt_cc
:
Procedure Dflt_CC integer item#
// s altera itens vazios que ainda no foram modificados
if (value(current_object, item#) ='' and ;
item_changed_state(current_object, item#) =0) begin
// primeiro assegura que o buffer est correto
send refind_records to (server(current_object))
set value item item# to Cust.CC_Num
set item_changed_state item item# to true
end
end_procedure
Utilizando os Arquivos de Sistema nos Dicionrios de Dados
Os arquivos de sistema do DataFlex foram desenvolvidos para conter apenas um
registro. Voc pode aplicar esse atributo configurando o nmero mximo de registros do
arquivo do banco de dados para 1 no Database Builder. Os arquivos de sistema podem
ser o arquivo principal ou um arquivo atualizado de um DDO, e devem ser tratados da
mesma forma que um arquivo relacionado.
Alm disso, os arquivos de sistema nunca podem ser limpos e seu (nico) registro nunca
deve ser excludo. Conseqentemente, os DDOs previnem essas duas operaes. Uma
vez que um registro do arquivo de sistema procurado automaticamente quando o
arquivo aberto, a procura manual do registro desnecessria. Como resultado, o nico
momento que um DDO reexibe os dados para um arquivo de sistema depois de uma
gravao no arquivo (se voc quiser reexib-los, voc pode enviar a mensagem
entry_display, passando o filenumber do arquivo de sistema explicitamente).
Freqentemente, os arquivos de sistema no so associados a um DDO. Os arquivos de
sistema representam a nica exceo regra de framework que diz que uma subclasse

79
U
s
a
n
d
o

D
D
O
s

data-dictionary deve ser criada e utilizada para cada arquivo de dados de uma aplicao.
Ao invs disso, voc pode nomear o arquivo em uma mensagem add_system_file, cuja
sintaxe :
add_system_file integer f i l e_number [ integer l ock_t ype]
Essa procedure adiciona o file_number estrutura do dicionrio de dados. utilizada
para arquivos de sistema e outros arquivos que, apesar de fazerem parte da estrutura de
travamento, no possuem seus prprios DDOs para se conectarem a estrutura de
dicionrio de dados. O Lock_type especifica o tipo de travamento que ser utilizado com
o file_number:
DD_lock_on_all Trava em todas as gravaes e excluses
DD_lock_on_new_save_delete Trava em novas gravaes e excluses
DD_lock_on_save Trava em todas as gravaes
DD_lock_on_new_save S trava em novas gravaes
DD_lock_on_delete S trava em excluses
Para arquivos de sistema que do suporte a um nmero serial de identificao, a opo
DD_lock_on_new_save deve ser suficiente; para arquivos que suportam contadores
que incrementam e decrementam, os outros dois modos podero ser necessrios, ento
a opo DD_lock_on_all seria apropriada. Os arquivos de sistema podem ser
desanexados com remove_system_file.
Send Add_System_File OrdSys.File_Number DD_Lock_On_New_save
Voc pode criar uma subclasse data-dictionary para o arquivo de sistema e um objeto e
conectar esse DDO a sua estrutura de dicionrio de dados. Se fizer isso, voc no
precisar gravar o arquivo de sistema em sua procedure creating; o DDO ir fazer isso
automaticamente. Se fizer isso, voc dever ter certeza que qualquer DDO que utilize
diretamente o arquivo de sistema, se conecta explicitamente ao DDO do arquivo de
sistema com um vnculo de atualizao. No exemplo a seguir, o cust omer e o or der
utilizam o arquivo de sistema sysf i l e para fornecer as chaves do registro. Os DDOs de
ambos fornecem um vnculo de atualizao com o DDO do arquivo de sistema:
object order_ent is an entry_view_client
object sysfile_dd is a Sysfile_DataDictionary
end_object
object customer_dd is a Customer_DataDictionary
set ddo_server to (sysfile_dd(current_object))
end_object

80
U
s
a
n
d
o

D
D
O
s

object Order_dd is an Order_DataDictionary
set ddo_server to (customer_dd(current_object))
set ddo_server to (sysfile_dd(current_object))
end_object
:
Constraints
Um constraint uma restrio que seleciona quais registros de um arquivo sero visveis
em um programa. Existem trs motivos para voc querer restringir um arquivo em um
DDO:
Quando um DDO se relaciona com outro, geralmente voc ir querer
que o DDO filho s exiba os registros que se relacionam com o registro
atual do DDO relacionado (pai). Um constraint relates-to (no DDO filho)
ir fazer isso para voc.
Voc pode querer que um DDO se assemelhe com um arquivo, mas
esse arquivo lgico uma seleo de registros de um arquivo maior.
Por exemplo: seu DDO customer pode ser um arquivo de nome e
endereo com propsitos gerais restringido a address.type eq
"customer". Um constraint com valor constante ir fazer isso para
voc.
Uma aplicao s pode se preocupar com um subconjunto de registro
de cada vez. Voc pode especificar os clientes e uma regio e/ou
taxas. Um constraint arbitrrio ir fazer isso para voc.
O Comando Constrain
O comando constrain pode ser utilizado das seguintes maneiras:
constrain order relates to customer
Geralmente, a declarao acima ser utilizada no DDO do or der ( pedi do) . Ela faz com
que todas as procuras no DDO s retornem registros que se relacionarem com o registro
cust omer ( cl i ent e) atual. Por exemplo: se o cliente Sandbag Quarry tiver sido
encontrado anteriormente no arquivo cust omer , uma procura no arquivo or der ser
restringida para procurar apenas pedidos para Sandbag Quarry.
constrain order.type eq "FUTURE"
Esse tipo de restrio ir requerer que todas as procuras do arquivo or der coincidam
com FUTURE. Se uma procura for feita e o registro no for FUTURE, o sistema
continuar procurando registros at que um satisfaa todas as restries. Aqui, voc

81
U
s
a
n
d
o

D
D
O
s

pode utilizar todos os operadores padres: lt, le, eq, ge, gt, ne. Voc tambm pode
utilizar contains, o qual requer que o campo contenha o valor, o que semelhante ao
eq, mas permite caracteres curingas (* e ?), e s trabalha com strings. O argumento do
valor da restrio pode ser de qualquer tipo de varivel, mas a restrio no ir mudar se
ocorrerem mudanas no valor das variveis. (Voc pode enviar a rebuild_constraints
para forar o valor alterado a ser utilizado, como ser discutido posteriormente.)
constrain order.recnum between 1 and 100
A restrio acima ir configurar um intervalo para o valor do campo. Em todos os outros
casos a sintaxe semelhante ao exemplo acima.
constrain customer as (((customer.name contains "DATA") or;
(customer.type ="COMPUTER")) and ;
(customer.area_code matches "3"))
A expresso de restrio acima a mais flexvel. Voc pode inserir qualquer expresso
que desejada, de qualquer nvel de complexidade. A expresso deve retornar um valor
verdadeiro ou falso. Geralmente voc utilizar expresses de comparao com and/or
para fazer isso. Voc tambm pode chamar funes com a expresso. No entanto,
devido a sua flexibilidade, esse o tipo de restrio mais lenta. A expresso avaliada
toda vez que um registro selecionado, para ver se este satisfaz a restrio. Alm disso,
uma restrio em forma de expresso no pode otimizar suas procuras (ela no pode
utilizar um ndice), e por isso ela pode ser muito lenta em arquivos grandes e/ou com
expresses complexas. Utilize outras formas de declaraes de restries sempre que
puder.
Programando Restries nos DDOs
Em um DDO, todas as suas declaraes de restrio so inseridas em um bloco de
restrio como o descrito a seguir:
Procedure OnConstrain
constrain order relates to customer
constrain order.type eq "FUTURE"
End_Procedure
Todas as restries no bloco so aditivas, quer dizer, todas elas devem ser satisfeitas
para um registro ser encontrado. As restries so construdas automaticamente quando
o DDO criado em tempo de execuo e ento so foradas por qualquer procura.
Conseqentemente, os arquivos de dados devem estar abertos quando o DDO
construdo. Observe que voc deve utilizar as mensagens de procura do DDO para que
as restries sejam utilizadas o comando find no respeitar as restries.

82
U
s
a
n
d
o

D
D
O
s

Como uma alternativa, voc pode utilizar o comando constrained_find, junto com
outros comandos orientados a restries. Veja a ajuda de Comandos on-line do
DataFlex para saber mais informaes sobre sua utilizao.
Geralmente, as restries pertencem a seus objetos servidores de dados e no s
classes servidoras de dados. As restries so utilizadas para limitar a visualizao dos
dados no programa. Esse tipo de restrio tende a ser baseada na necessidade de um
tipo de visualizao ao invs de ser baseada em uma regra geral do banco de dados.
Restries Variveis
Voc pode ter restries que se alterem conforme a entrada do usurio ou outras
condies. Por exemplo, voc pode querer que os usurios preencham o campo pa s do
cliente com os quais ir negociar, e ento se restringe o DDO para apenas esse pas.
Uma vez que as restries so construdas quando o objeto construdo, essas
alteraes nos constraints no tm efeito (exceto em restries em forma de expresso,
que sempre so avaliadas). Sempre que o critrio em que as restries esto baseadas
for alterado, envie a mensagem rebuild_constraints para o DDO. Desta forma, as
restries sero reconstrudas com os valores atuais dos dados. Geralmente, depois da
alterao de uma restrio, poder ocorrer que seu registro atual no faa mais parte do
conjunto de restrio vlido. Por isso, voc freqentemente precisar procurar um novo
registro depois de reconstruir uma restrio.
No exemplo a seguir, um DEO envia uma mensagem para seu DDO, passando dois
parmetros, o novo valor da restrio e o ndice que deve ser utilizado para procurar o
registro:
Object Customer_DD is a customer_dataDictionary
property string status_constraint public ''
Procedure Constraint_by_status string stat integer ndx
integer file#
get main_file to file#
Set status_constraint to stat
send rebuild_constraints
send request_find FIRST_RECORD file# ndx
end_procedure
Procedure OnConstrain
string stat
get status_constraint to stat
if (stat <> '') constrain Customer.status eq stat

83
U
s
a
n
d
o

D
D
O
s

End_Procedure
end_object
Otimizao da Procura com Restrio
Se o DDO tivesse que ler todo o banco de dados em cada procura, os usurios iriam
esperam muito tempo para encontrar um registro ou um conjunto deles. O DDO tentar
otimizar a procura utilizando o ndice que voc programou para procura. Sempre que
uma procura for executada, as restries so avaliadas pelo ndice em uso para verificar
se pode ser feita alguma otimizao. Isso automtico voc no precisa fazer
nenhuma programao adicional para acontecer. No entanto, se o ndice atual no puder
ajudar na procura, o DDO ter que ler todo o banco de dados. Se voc no fizer com
que o banco de dados sempre utilize um ndice particular para assegurar uma procura
rpida, voc deve especificar uma ordem no DDO com a clusula by index.#. A
especificao de uma ordem faz com que todas as procuras (incluindo as que foram
iniciadas pelos usurios) utilizem esse ndice.
Tpicos Avanados do Dicionrio de Dados
Controlando as Excluses em Cascata
O comportamento de excluses em cascata discutido acima. Um DDO ir excluir todos
os registros relacionados de todos os arquivos de dados descendentes se estes forem
parte da estrutura servidora de dados e se um relacionamento de arquivo existir entre os
arquivos. Em alguns casos, isso o que voc desejar; e em outros, voc no ir querer
que isso acontea. Onde no quiser que haja excluses dos registros do arquivo
principal que tenham registros filhos, voc deve utilizar a propriedade
cascade_delete_state. O padro do DataFlex para essa propriedade true para todos
os DDOs, fornecendo, assim, o comportamento que permite a excluso em cascata.
Voc pode alter-la para todos os DDOs nos programas que voc compilar alterando a
linha
DEFINE DEFAULT$CASCADE$DELETE$STATE FOR TRUE
que est no DFALLENT.PKG, para FALSE. Como uma alternativa, voc pode configurar
a propriedade para false individualmente em cada DDO (e/ou em suas classes).
Com a configurao da propriedade para false, no ser permitida a excluso de
registros filhos (mesmo se existirem filhos). Esse no o objetivo dessa mensagem.
Espera-se que voc identifique no DDO principal, os arquivos filhos que voc quer que
essa proteo seja baseada. Isso pode ser feito com a mensagem add_client_file, com
um argumento do nmero do arquivo que voc quer que tenha a proteo. Voc deve

84
U
s
a
n
d
o

D
D
O
s

fornecer uma mensagem para cada arquivo filho que desejar, geralmente, na procedure
construct_object da definio da subclasse data-server.
Quando isso feito, o registro do arquivo principal no ser excludo quando um arquivo
filho declarado contiver um registro que se relacione com o registro a ser excludo. Se
nenhum arquivo filho declarado contiver um registro relacionado, mas um arquivo filho
no declarado contiver esse registro, o registro do arquivo principal ser excludo, e os
registros filhos que estiverem nos arquivos no declarados no sero. Esse
comportamento no desejvel, por isso, voc deve ter certeza que listou todos os
arquivos filhos apropriadamente.
A verificao dos arquivos declarados feita por uma procedure chamada pela funo
validate_delete, a validate_delete_no_cascade. Se tiver sua prpria definio da
validate_delete, voc deve executar um forward get validate_delete para ter a
proteo da excluso em cascata.
Se a validate_delete_no_cascade verificar que um arquivo declarado no est aberto,
ela chamar a operation_not_allowed com o nmero de erro como argumento, o que
produzir a mensagem Cannot delete - related files not open (No possvel excluir
os arquivos relacionados no esto abertos). Se ela encontrar um arquivo
declarado com um registro filho relacionado, ela enviar a mesma procedure com o
argumento Cannot delete - related records exist (No possvel excluir existem
registros relacionados). Se precisar executar validaes customizadas de excluso em
cascata, voc deve aumentar a funo. Se quiser interromper a excluso, voc deve
enviar a mensagem junto com um nmero de erro apropriado.
Voc pode remover os arquivos protegidos da lista de arquivos com a mensagem
remove_client_file. Voc pode perguntar o nmero dos arquivos protegidos que esto
na lista com a funo client_file_count, e pode adquirir o nmero do arquivo que estiver
em uma posio particular da lista com a funo client_file. No comum que voc no
precise utilizar essas mensagens.
O padro da propriedade true para todos os DDOs, o que significa que a excluso em
cascata ser permitida. Voc pode alterar esse padro para todos os DDOs nos
programas que voc compilar alterando a linha
DEFINE DEFAULT$CASCADE$DELETE$STATE FOR TRUE
Que est no ALLENTRY.PKG para false. (Lembre-se de recompilar). Voc pode
configurar a propriedade para false individualmente nas subclasses e/ou objetos data-
server.

85
U
s
a
n
d
o

D
D
O
s

Travamento Inteligente do Arquivo de Dados
O comportamento padro de gravao ou excluso travar e reler todos os arquivos
abertos durante no file list durante o tempo necessrio para efetivar a gravao no disco.
Em uma estrutura de vrios arquivos relacionados, com vrios rereads no pai, e
algumas vezes nos filhos, isto pode interromper as atividades de gravao de outros
usurios (no impede atividades de procura ou edio).
Os DDOs suportam uma caracterstica chamada smart filemode que pode melhorar a
performance das gravaes e excluses. Isso controlado por uma propriedade do DDO
chamada smart_filemode_state. Quando todos os DDOs de uma estrutura de
dicionrio de dados configurarem essa propriedade para true, apenas os arquivos de
dados que participarem da operao atual sero travados e relidos. Isso pode melhorar
a performance das estaes que esto executando a operao, bem como nas estaes
que no estiverem executando essa operao neste momento (h um menor trfico na
rede).
Utilizao Bsica do Smart-Filemode
A utilizao do smart filemode muito fcil. Quando uma gravao ou excluso ocorrer,
o DDO que estiver executando essa operao ir procurar por todos os DDOs
participantes que estiverem na estrutura. Se o smart_filemode_state for true para
todos esses DDOs, o DDO utilizar o travamento com smart-filemode.
Por padro, o smart-filemode est habilitado em objetos dicionrio de dados. Se por
alguma razo sua estrutura de DDOs no puder suportar o smart-filemode, voc pode
desabilit-lo configurando o smart_filemode_state para false. Deve-se configurar isso
dentro da procedure define_fields da subclasse. Voc deve evitar isso, e, ao invs
disso, deve aplicar seus esforos na criao de uma estrutura de arquivo de dados que
suporte o smart filemode.
Class Myfile_DataDictionary is a DataDictionary
forward send Define_Fields
set main_file to myfile.file_number
set smart_filemode_state to false
:
end_procedure
:
end_class

86
U
s
a
n
d
o

D
D
O
s

Por padro, o smart filemode desabilitado nos data sets e devem ser habilitados
configurando smart_file_mode_state para true. Voc deve configurar esta propriedade
dentro da procedure construct_object da subclasse.
Class Myfile_DS is a DataSet
Procedure Construct_Object
set smart_filemode_state to true
:
end_procedure
:
end_class
Tratando Arquivos fora da Estrutura
O smart filemode funciona bem para todos os DDOs que s utilizam arquivos de dados
que so conhecidos pela estrutura servidora de dados (o main_file de cada DDO
participante). O que aconteceria se voc precisasse utilizar um arquivo de dados que
no fosse conhecido pela estrutura servidora de dados? Geralmente, os arquivos de
sistema s so utilizados pela procedure creating (para criar chaves de registro
fornecidas pelo sistema). Os arquivos desse tipo so considerados como
desconhecidos para os DDOs envolvidos, e sua manipulao com o smart-filemode
requer certos passos alm dos descritos acima.
Tratando Arquivos Desconhecidos nos Dicionrios de Dados
Voc pode informar ao dicionrio de dados sobre os arquivos desconhecidos enviando
a mensagem send add_system_file. Ela diz para o DDO que o nmero de arquivo
enviado deve ser travado durante gravaes e excluses. Um parmetro adicional de
tipo de travamento pode ser enviado, permitindo que voc especifique sob quais
condies o arquivo deve ser travado (lock on all [o padro], lock on save, lock on new
save, lock on new save and delete, e lock on delete).
No exemplo a seguir, a subclasse data-server est informando ao DDO que um arquivo
de sistema tambm deve ser travado, mas somente durante a gravao de um registro
novo:
Class Myfile_DD is a DataDictionary

87
U
s
a
n
d
o

D
D
O
s

send add_system_file sysfile.file_number dd_lock_on_new_Save
define_auto_increment sysfile.counter to myFile.ID
:
end_procedure
:
end_class
Se voc usa data sets e no dicionrios de dados ou se no precisar manipular
condies mais complicadas do arquivo desconhecido, voc deve aumentar a procedure
reset_filemodes_for_lock.
Manipulando Arquivos Desconhecidos nos Data Sets
Utiliza-se a procedure reset_filemodes_for_lock para informar um data set sobre os
arquivos desconhecidos. Depois de executar um forward send na mensagem, voc
pode configurar o filemode de qualquer arquivo manualmente. Geralmente, voc ir
configurar o filemode dos arquivos desconhecidos para leitura/escrita (default). A
mensagem reset_filemodes_for_lock enviada para todos os DSOs em uma estrutura
servidora de dados.
No exemplo a seguir, a subclasse data-set est utilizando o smart filemode e est
informando o data set que um arquivo de sistema tambm deve ser travado:
Class Myfile_DS is a Dataset
Procedure construct_object
set smart_filemode_state to true
end_procedure
procedure reset_filemodes_for_lock
forward send reset_filemodes_for_lock
file_mode sysfile default
end_procedure
:
end_class

88
U
s
a
n
d
o

D
D
O
s

Se seu arquivo de sistema for controlado atravs de seu prprio DSO relacionado para
atualizao, voc no precisar fazer isso. O DSO j saber sobre esse arquivo de
sistema porque ele faz parte da estrutura servidora de dados.
Otimizando o Acesso ao Arquivo de Sistema
Apesar dos fatores de acesso ao arquivo e de tempo de gravao terem sido
melhorados com o smart filemode, o acesso aos arquivos de sistema compartilhados por
vrios usurios, ainda pode apresentar um gargalo. Um mtodo para aliviar esse
problema dividir os campos do arquivo de sistema que precisam ser gravados em
grupos que possam ser utilizados independentemente dos outros. Freqentemente, um
nico campo forma esse grupo. Cada um deles pode ser movido para seu prprio
arquivo de sistema. Apesar disso ser muito efetivo, existe a desvantagem de requerer
mais arquivos de dados em sua lista de arquivos. Voc pode ficar sem lugar para essas
novas entradas.
Uma alternativa simples para um tipo comum de arquivo de sistema que s precisa ser
travado quando um novo registro estiver sendo criado, seria tornar a alterao do
filemode exibida no exemplo acima, condicional. A declarao send add_system_file
seria estendida para algo como o que est exibido em negrito:
add_system_file sysfile.file_number DD_lock_on_new_save
Neste exemplo, s travamos o arquivo de sistema quando precisarmos utiliz-lo. S
precisamos dele quando um novo registro estiver sendo salvo.
Se voc estiver utilizando data sets, isso seria codificado na reset_filemodes_for_lock
da seguinte maneira:
Procedure Reset_Filemodes_for_lock
Local integer crec
Forward Send Reset_Filemodes_for_lock
Get Current_Record to crec // se for 0, um novo registro
// s trava o arquivo de sistema de precisarmos dele.
// Precisamos dele quando gravamos um novo registro
If (crec = 0) file_mode sysyfile Default
End_Procedure
Como o Smart Filemode Funciona
Quando um pedido de gravao ou excluso enviado para um DSO, ocorre
o seguinte:

89
U
s
a
n
d
o

D
D
O
s

Verifica se o smart filemode deve ser utilizado.
A propriedade smart_filemode_state de todos os DSOs participantes
verificada. Se qualquer propriedade smart_filemode_state for falsa, o
travamento inteligente de arquivo no ser utilizado (e os passos
seguintes no sero executados).
Grava os filemodes atuais de todos os arquivos.
Os filemodes de todos os arquivos so registrados em um array
interno.
Configura os filemodes de todos os arquivos para somente leitura.
Os arquivos so configurados para o valor da propriedade
smart_filemode_for_no_lock (que DF_FILEMODE_READONLY por
padro), fazendo exceo para lock pelo programa onde isso est
acontecendo.
Todos os filemodes dos arquivos participantes so configurados para
leitura/escrita.
A mensagem reset_filemodes_for_lock enviada para todos os DSOs
participantes, onde ela configura os filemodes dos arquivos
participantes para o valor da propriedade smart_filemode_for_lock (o
modo original, por padro). Quaisquer aumentos customizados
ocorrem nesse ponto (tal como marcar um arquivo de sistema para a
participao).
A gravao/excluso executada.
S os arquivos com o filemode diferente de
DF_FILEMODE_READONLY so travados e relidos.
Os filemodes de todos os arquivos so restaurados para seus estados
originais.
Smart Filemode e Arquivos Fantasmas
O comportamento padro do smart filemode leva em conta os arquivos fantasmas
(filemode como alias ou master_alias) que estiverem participando da
gravao/excluso. O arquivo principal configurado para o modo
smart_filemode_for_lock, mas com a parte do DF_FILEMODE_NO_LOCKS desligada
(com isso o arquivo alias principal fica sempre travado). Todos os arquivos de alias so
configurados de acordo com a participao ou no da gravao/excluso, mas com a
parte do DF_FILEMODE_NO_LOCKS ligada (com isso os arquivos alias nunca so
travados). Os arquivos alias principais so travados e relidos, enquanto os arquivos alias
so relidos e nunca so travados, o que evita uma condio de deadlock. O smart

90
U
s
a
n
d
o

D
D
O
s

filemode utiliza o valor do atributo DF_FILE_ALIAS do arquivo para decidir o que deve
ser feito.
O valor padro do smart_filemode_state false. Voc pode configurar o estado true
em subclasses individuais do dicionrio de dados, ou at nos DDOs, mas deve saber
que o smart filemode no funcionar se qualquer um dos DDOs participantes da
gravao ou excluso tiver o smart_filemode_state configurado para false.
Se voc quiser que todos os DSOs usem o smart filemode como padro, voc pode criar
a seguinte configurao padro global no DFALLENT.PKG:
DEFINE DEFAULT$SMART$FILEMODE$STATE FOR TRUE
Se voc fizer isso, lembre-se de re-pr-compilar seu pacote dfallent.
Mecanismo de Atualizao
Os DDOs so designados para informar todos os objetos de entrada de dados sobre
qualquer alterao nos dados do DDO. Uma alterao ocorre sempre que for solicitada a
um DDO uma procura, limpeza, gravao, ou excluso de um registro. Uma estrutura
servidora de dados faz isso enviando a mensagem refresh para todos os DDOs
afetados. O mecanismo de atualizao utilizado pelas classes data-dictionary para
assegurar que cada DEO receba uma e apenas uma mensagem refresh por operao
do dicionrio de dados (por exemplo, find, clear, save, delete, superfind), sem levar
em considerao o nmero de DDOs aos quais cada DEO est anexado. Quando uma
procura for executada por um DDO, os outros DDOs podem ser requeridos para
executar uma procura ou possivelmente uma limpeza. Como resultado, iremos, muitas
vezes, precisar exibir itens de alguns arquivos ao mesmo tempo que outros itens de
outros arquivos estiverem sendo limpos.
Quando um objeto de entrada de dados receber uma mensagem refresh (uma
mensagem protegida enviada pelos DDOs para os DEOs), ele exibir ou limpar os
dados baseado no modo de atualizao (veja abaixo) e no status da ltima operao do
arquivo (o registro foi encontrado, o registro foi limpo, no houve alterao). Baseado
nessas condies, o DEO enviar as mensagens entry_clear e/ou entry_display.
Geralmente, a refresh definida como uma procedure com um argumento, o modo, que
o evento ou operao que gerou essa mensagem refresh, da seguinte forma:
procedure refresh integer mode
Os modos esto descritos abaixo.
mode_clear
Este modo s utilizado somente para objetos de entrada de dados (DEOs) que
estiverem anexados ao DDO que foi a origem de uma operao de limpeza, isto , o

91
U
s
a
n
d
o

D
D
O
s

DDO que recebeu o pedido ou mensagem original de limpeza como resultado do
pressionamento da kclear pelo usurio. Todos os outros DDOs enviam a seus DEOs a
mensagem refresh com mode_find_or_clear_set.
mode_find_or_clear_set
Este modo utilizado para os DEOs que estiverem anexados ao DSOs que fizeram uma
procura e/ou limpeza de registros como resposta a um pedido de procura do usurio
(kfind, kfind_next, ksuperfind, etc) ou como resposta a outra procura ou limpeza do
DDO.
mode_clear_all
Este modo utilizado para os DEOs que estiverem anexados a qualquer DDO que
participou de uma operao clear_all.
mode_delete
Este modo utilizado para os DEOs que estiverem anexados a qualquer DDO que
executou uma excluso bem sucedida. Os DDOs que foram meramente atualizados
como resultado de uma excluso utilizam mode_find_or_clear_set.
mode_save
Este modo utilizado para os DEOs que estiverem anexados a um DDO envolvido em
uma operao de gravao bem sucedida.
A ao refresh enviar entry_clear 1 seguida da entry_display 0 0; isto , a
refresh executa uma operao de limpeza e exibio simultaneamente.
A mensagem refresh implementada na classe bsica entry e tambm nas classes
data_list e dbEdit.
O Comando Is_file_included
As mensagens entry_update, entry_display, e entry_clear afetam os campos que
foram afetados pela ltima operao do banco de dados. Quando se aumentam essas
mensagens, os parmetros enviados so apenas avanados sem nenhuma alterao.
No entanto, em alguns casos especiais, pode ser necessrio determinar quais arquivos
foram (ou sero) afetados.
O comando is_file_included fornecido com esse objetivo. Ele aceita dois argumentos:
o primeiro o nmero do arquivo a ser verificado, e o segundo deve ser 1 ou 0,
dependendo se voc quiser saber se a ltima operao do banco de dados executou

92
U
s
a
n
d
o

D
D
O
s

uma limpeza (0) ou uma procura (1) no arquivo em questo. Esse comando configura o
indicador found para true se o arquivo foi includo, e false caso contrrio.
procedure entry_display integer file# integer display_all
local integer dispv
forward send entry_display file# display_all
// queremos saber se o arquivo vehicle foi limpo, pesquisado, ou se
// no foi alterado
is_file_included vehicle.file_number 1 // O registro foi encontrado?
if [found] Begin // Sim, foi encontrado. Execute
: // a customizao da procura
end
else begin // se foi limpo ou no foi afetado
is_file_included vehicle.file_number 0
// O buffer foi limpo?
if [found] Begin // Sim, foi limpo. Execute
: // a customizao da limpeza
end
else ...
// Se chegar aqui, o arquivo no foi posicionado nem limpo
end
end_procedure

Novamente, no se espera que voc precise utilizar esse comando em programas
tpicos.
Os Inteiros de Operao do Dicionrio de Dados
Dois inteiros globais so mantidas durante operaes do dicionrio de dados:
operation_origin e operation_mode. Esses valores so mantidos pelo sistema e no
devem ser alterados. Eles podem ser solicitados e fornecem informaes valiosas sobre
uma operao do banco de dados.
Quando uma operao principal do dicionrio de dados comea, o DDO verifica a
operation_mode para ter certeza que no h outra operao servidora de dados em
processo. Visto que as operaes servidoras de dados no podem ser executadas ao

93
U
s
a
n
d
o

D
D
O
s

mesmo tempo (apenas uma por vez), o valor da operation_mode deve ser
mode_waiting. A operation_mode configurada baseando-se no tipo da operao
(limpeza, procura, gravao, excluso). Quando a operao estiver completa, a
operation_mode restaurada novamente para o mode_waiting. As operaes clear e
clear-all configuram-na para mode_clearing. As operaes find e superfind configuram-
na para mode_finding. A operao de gravao a configura para mode_saving, e a de
excluso para mode_deleting.
Em aplicaes avanadas, voc pode utilizar o valor da operation_mode para executar
adies customizadas. Por exemplo: voc pode precisar de dois comportamentos da
backout, um para a gravao e outro para excluso:
Procedure Backout
if (operation_mode = mode_deleting) Begin
: // backout customizada para excluso
end
else Begin // se no estiver excluindo, deve estar gravando
: // backout customizada para gravao
end
end_procedure
No exemplo a seguir, utilizaremos a operation_mode dentro da procedure
operation_not_allowed para determinar se o erro que est sendo enviado um erro de
gravao ou excluso:
procedure operation_not_allowed integer err#
if (operation_mode = mode_saving) ;
error err# "- Save Error"
else if (operation_mode = mode_deleting) ;
error err# "- Delete Error"
else ;
forward send operation_not_allowed err#
end_procedure
A operation_origin indica qual DDO iniciou a operao do dicionrio de dados. Ela
contm a ID do objeto do DDO. Os valores da operation_mode e da operation_origin
sempre so configurados ao mesmo tempo. A operation_origin 0 quando nenhuma
operao servidora de dados est em progresso.

94
U
s
a
n
d
o

D
D
O
s

A operation_origin foi criada com o nico objetivo de fornecer mais informaes sobre
uma operao servidora de dados ao desenvolvedor.
Neste exemplo, utilizaremos a operation_origin para assegurar que um registro novo
nunca ser gravado quando estiver sendo utilizado como pai (isto , se o registro no
do main_file do DDO que recebeu a mensagem request_save):
Function Validate_Save returns integer
Local integer rval crec
Get current_Record to crec // se for 0, novo
If (crec= 0 AND Operation_Origin <>Current_Object) ;
Error 304 "Can't save this parent record at this time."
// s chegaremos aqui se tudo ainda estiver ok
function_Return rval
end_function
Uma outra aplicao da operation_origin e da operation_mode pode ser no sistema
de rastreamento de erros. Em uma aplicao tpica, todos os erros so enviados para
um nico manipulador de erro (objeto). Voc pode decidir que voc criar e registrar
erros de gravao e de excluso do DDO. Dentro de seu objeto de erro, voc pode
determinar se o erro foi um erro do dicionrio de dados (verificando se a
operation_mode no igual a mode_waiting), qual operao servidora de dados
estava sendo executada (olhe novamente na operation_mode), e em qual DDO ele
ocorreu (olhe na operation_origin).
Auto-preenchimento e Dicionrios de Dados
Os DDOs tm uma propriedade chamada auto_fill_state. Geralmente, essa propriedade
no alterada pelos programadores, mas mantida pelo DDO levando em conta se
uma grid est sendo ou no utilizada como um de seus objetos container de entrada de
dados. Quando uma grid um dos DEOs que utilizam um certo DDO, a auto_fill_state
desse DDO padronizada como true. Isso faz com que o DDO refaa a procura dos
registros que satisfazem as restries (se houverem), ocasionando a exibio constante
de todos os registros que satisfazem as restries na grid.
Todos os objetos de entrada de dados tambm suportam a mesma propriedade: as grids
padronizam-na para true, fazendo com que seu servidor tambm seja padronizado como
true, enquanto os outros objetos de entrada de dados utilizam false como padro. Se
voc alterasse a auto_fill_state de um form para true, seu DDO tambm iria ser
alterado para preencher automaticamente, e tentaria encontrar o primeiro registro que

95
U
s
a
n
d
o

D
D
O
s

satisfizesse as restries. Isso significa que o entry form, da mesma forma que a grid,
exibiria os dados sempre que fosse possvel.
As mensagens e propriedades a seguir podem ser enviadas e utilizadas com os DDOs
para controla e executar partes especficas dos comportamentos do dicionrio de dados:
Gravando e Excluindo
Voc pode enviar request_save ou request_delete para o DDO com o objetivo de
imitar o pressionamento da tecla de gravao (F2) (excluindo as operaes de
validao, verificao, e de auto-limpeza do item) ou da tecla de excluso (Shift+F2)
(excluindo as operaes de verificao e de auto-limpeza). Se quiser alterar uma ao
padro dessas operaes de gravao e excluso para um certo objeto de entrada de
dados, voc pode sobrescrever as mensagens request_save e/ou request_delete
nesse objeto para que ele envie a request_save e/ou request_delete para o DDO
apropriado. Os filemodes no_delete_state e read_only tambm afetam a maneira como
estas mensagem iro atuar. A excluso tambm afetada pelo valor da
cascade_delete_state.
Validao e Constraints
A mensagem request_validate pode ser enviada para ocasionar a validao dos itens
dos objetos de entrada de dados do DDO. Esse tipo de validao executado
automaticamente pelo DDO como parte da operao de gravao. A mensagem
rebuild_constraints deve ser enviada para reinicializar as restries se elas forem
alteradas depois de serem inicializadas pela primeira vez. Voc tambm deve enviar
algum tipo de mensagem de procura posteriormente para assegurar que o registro atual
do DDO satisfaz as novas restries.
Validao do Item
A validao do item nos DEOs ocorre sob duas condies: navegao e gravao.
Uma propriedade, chamada validate_mode, est presente nos dbForms e nas dbGrids
(a partir da classe validate_mixin). Ela pode ser configurada para qualquer um dos
seguintes modos: validate_default, validate_on_save, e validate_on_save_next. Os
forms tm como padro a validate_default. Os grids tm como padro a
validate_on_save_next, a qual limita a validao do item sada da linha atravs da
navegao (Next) ou gravao. Isso ajuda a navegao da grid suprimindo erros
artificiais que poderiam ocorrer durante a entrada de dados nas linhas.

96
U
s
a
n
d
o

D
D
O
s

Validao durante a Navegao do Item
Quando os usurios navegam para frente em uma grid, ocorre a validao do item. A
ocorrncia mais comum dessa validao quando o cursor avana um item (atravs do
pressionamento da tecla Tab). Se os usurios moverem o cursor vrios itens para frente
em um grid ou form, a validao ocorrer cada item entre o primeiro e o ltimo item onde
o cursor estiver localizado. Se eles navegarem diretamente do item 5 para o 8 com o
mouse, os itens 5, 6, e 7 sero validados.
Em navegaes para trs em um form, a validao do item no ocorre. A navegao
entre objetos tambm no inicia a validao de item para todos os itens. Isso significa
que possvel navegar para frente (entre os objetos) sem iniciar a validao do item, o
que em algumas ocasies pode ser indesejado.
Validao da Gravao
Antes de um DDO tentar gravar um registro, ele ir, primeiro, validar todos os itens
apropriados de todos os DEOs que participarem da gravao. Isso significa que todos os
itens sero validados antes que uma gravao ocorra. Se alguma validao do item
falhar, a gravao ser interrompida e o item que falhou recebe o foco. A validao
iniciada pelo DDO enviando a mensagem validate_items para todos os DEOs
conectados. A mensagem validate_items envia, individualmente, a mensagem
iValidate para cada item do DEO (ou no caso de ser uma grid, para cada item da linha).
No confunda isso com a funo validate_save do DDO. As validaes que acabaram
de ser descritas ocorrem antes da gravao (e antes de os arquivos serem travados), A
funo validate_save, chamada durante o estado de travamento, antes da gravao
do registro atual, para verificar os valores do banco de dados que possam ter sido
alterados durante a entrada do registro (geralmente como resultado de aes de outros
usurios).
Uma propriedade chamada validate_all_items_state fornecida para dizer se uma
validao do item est sendo chamada como parte da navegao ou gravao. Se o
valor dela for true, quer dizer que o item est sendo validado como parte de uma
gravao e se for false, o item est sendo validado durante a navegao no item.
Programando a Validao do Item de Acordo com a Forma Usada
Em um sistema 100% dirigido a eventos, o programa no faz suposies sobre em qual
ordem os dados sero inseridos. Os usurios devem ter permisso para inserir os dados
de cima para baixo, de baixo para cima, ou de qualquer outra forma. Quando as
aplicaes so utilizadas dessa forma, a validao na navegao para frente no faz
sentido. Em um ambiente 100% dirigido a eventos, toda validao do item deve ser
processada durante a gravao.

97
U
s
a
n
d
o

D
D
O
s

Em uma utilizao que no dirigida a eventos, o processamento feito de cima para
baixo em um form (ou da esquerda para a direita em um grid) e em um item por vez. Se
os usurios navegarem para traz, provavelmente ser para fazer correes e depois iro
navegar para frente novamente. Neste tipo de ambiente, a validao do item pode ser
realizada apenas durante navegao para frente.
Um programa real de entrada de dados uma mistura desses dois estilos. Mesmo que o
sistema seja inteiramente dirigido a eventos, a maioria dos usurios ir utiliz-lo, na
maior parte do tempo, como se no fosse dirigido a eventos. Em outras palavras, a
maior parte dos programas de entrada de dados consistem quase completamente da
navegao para frente entre os itens (geralmente executada pela tecla Tab). Tentar tirar
a melhor vantagem da validao do item nesse tipo de ambiente um desafio. Apesar
de no existir nenhuma soluo perfeita, o DataFlex fornece vrios modos de validao,
permitindo que voc satisfaa da melhor forma a validao dos itens em suas aplicaes
e as maneiras nas quais elas deveriam ser utilizadas.
A Propriedade Validate_mode
A propriedade validate_mode determina sob quais condies a validao do item
ocorrer. Os trs modos so:
Validate_default Este modo faz com que a validao do item funcione exatamente da
mesma forma que no DataFlex. Se a propriedade object_validation for true (o que
geralmente ), a validao ocorrer durante a navegao para frente dentro de um DEO
e durante uma gravao (quando todos os itens sero validados). Se a
object_validation for false, a validao do item no ocorrer durante a navegao ou
gravao. Durante uma gravao, a validao no ser realizada nos DEOs que tiverem
a object_validation configurada para false.
Esta a forma de validao de item mais intensiva. Ele funciona bem com os entry
forms e o validate_mode padro dos objetos dbForm.
Observe que a validao do item no ocorre em todas as navegaes para frente.
Quando os usurios avanam para o prximo objeto, nem todos os itens entre o
current_item do objeto antigo e o current_item do novo objeto sero validados. Por
isso, importante que todos os itens sejam validados durante uma gravao.
Validate_on_save Quando este modo for selecionado, a validao do item s ocorrer
durante uma gravao. a melhor opo para um sistema 100% dirigido a eventos. Ela
permite que os usurios insiram os dados em qualquer ordem que quiserem. Uma
entrada invlida no ser reconhecida at que haja um pedido de gravao.
Validate_on_save_next Este modo representa uma meio temo entre os outros dois
modos. A validao do item ocorrer durante uma gravao e durante a navegao
atravs da mensagem next. Geralmente, a mensagem next enviada pela tecla Tab.

98
U
s
a
n
d
o

D
D
O
s

Este o validate_mode padro da classe Grid, mas voc tambm pode observar que
ele funciona bem com os entry forms. Os grids tm a tendncia de produzir erros de
validao indesejados durante a navegao em linhas vazias e entre objetos. Este modo
deve resolver esses problemas.
Basicamente, ele age semelhantemente ao modo validate_on_save (s validando
durante uma gravao) com uma nica concesso para a entrada de dados
procedurais (Tab produz uma validao). Essa concesso fornece a validao do item
durante a navegao mais comum de entrada de dados, ao mesmo tempo em que
fornece a flexibilidade para todos os outros tipos de navegao. Isto visto como um
bom meio termo.
Object_validation and Validate_mode
Para os modos validate_on_save e validate_on_save_next funcionarem
apropriadamente, a propriedade object_validation deve ser configurada para false. A
configurao do validate_mode para qualquer um desses modos tambm configurar a
object_validation para false. Se voc configurar o validate_mode para
validate_default, a propriedade object_validation tambm ser configurada para true.
Se, por alguma razo, voc precisar alterar a propriedade validate_mode para
validate_default e quiser que a propriedade object_validation seja false, voc deve
primeiro configurar a validate_mode e ento a object_validation.
Controlando as Conexes do DDO
Vrias mensagens controlam como os DDOs so vinculados a outros DDOs e como os
objetos de entrada de dados so vinculados aos DDOs. Geralmente, essas conexes
so mantidas automaticamente. Tudo o que voc precisa saber fazer utilizar os
vnculos set ddo_server (updating) e set server (using). Essas mensagens sero
discutidas brevemente aqui e apresentadas em mais detalhares na Referncia de Classe
do Visual DataFlex. Essa uma discusso muito tcnica. Provavelmente, voc nunca
precisar utilizar essa informao.
Conectando os DDOs aos DDOs
Um DDO cliente (filho) anexado a seu DDO servidor (pai) com a mensagem
DDO_server. Essa mensagem enviada para o DDO cliente com o object ID do DDO
servidor como o nico parmetro.
A mensagem detach_server ir remover uma conexo entre um DDO cliente (que
recebe essa mensagem) e um DDO servidor (cujo object ID enviado como o nico
parmetro). Nenhum desses pacotes utiliza esse mtodo. A conexo e desconexo

99
U
s
a
n
d
o

D
D
O
s

dinmica dos DDOs clientes e servidores so consideradas uma tcnica muito
avanada.
Conectando os DEOs aos DDOs
Quando a propriedade server de um DEO configurada para o ID do DDO declarado,
ele sabe quem seu servidor, mas um vnculo cliente-sevidor bi-direcional ainda no foi
criado. Neste ponto, o DDO no sabe nada sobre o DEO.
Sempre que um DEO se torna ativo, ele envia a mensagem add_user_interface para
seu DDO com o objetivo de notificar sua ativao. Durante esse processo, criado um
vnculo entre o DEO e seu DDO servidor e o DEO e quaisquer outros DDOs cujos
arquivos de dados puderem estar referenciados no DEO. Estes so chamados watched
servers (servidores vigiados). Quando a mensagem add_user_interface enviada
para os watched servers, um parmetro integer adicional (true) transmitido, notificando
o DDO que ele um watched server.
Agora, sempre que o DDO executar uma operao que deva afetar seus objetos de
entrada de dados, estes recebero a mensagem apropriada. Quando um DEO
desativado com seu changed_state configurado como false, ou quando seu
changed_state estiver configurado como false quando o objeto no estiver ativo, o
objeto de entrada de dados enviar a remove_user_interface para o DDO com o
objetivo de notificar o mesmo que ele no precisa se comunicar com o DDO at que
seja ativado novamente. A mensagem remove_user_interface tambm enviada para
todos os watched servers, novamente passando o parmetro adicional (true) indicando
que uma conexo do watched-server est sendo cortada.
Observao: Este mtodo de criao e remoo dos vnculos de entrada de
dados pode mudar no futuro.
Pesquisando as Listas de Conexo de um DDO
Os DDOs mantm listas que permitem que eles possam observar os DDOs servidores,
os DDOs clientes, os DEOs clientes, os arquivos de dados de atualizao, e os arquivos
cliente-servidor esperados. Trs listas contm os arquivos do banco de dados, duas
contm outros DDOs, e uma contm os DEOs.
No se espera que o programador necessite acessar essas listas em aplicaes
normais. As mensagens podem ser teis para o desenvolvedor avanado (aqueles
desenvolvedores que criam subclasses data-server estendidas). Essas mensagens
tambm podem ser teis durante o processo de verificao de erros. Freqentemente,
os erros do programa so um resultado das conexes DDO-para-DDO e DEO-para-DDO
imprprias. Essas propriedades permitem que seu programa verifique essas conexes.

100
U
s
a
n
d
o

D
D
O
s

Data_set_server List
Esta a lista de todos os DSOs servidores. Os servidores so adicionados lista
atravs da mensagem set ddo_server ou attach_server. Os servidores so removidos
da lista (o que raramente feito) com a mensagem detach_server. O nmero de DSOs
na lista pode ser consultado com a funo data_set_server_count, e o ID de um DSO
em uma posio particular da lista devolvido pela funo data_set_server.
Data_set_client List
Este o espelho da lista servidora de dados. Sempre que um vnculo servidor de dados
cliente/servidor estabelecido, o DDO cliente adiciona o object ID do servidor sua lista
de servidores (veja acima) e o DDO servidor adiciona o object ID do cliente sua lista de
clientes. O nmero de DDOs da lista pode ser consultado com a funo
data_set_client_count, e o ID de um DDO em uma posio particular da lista
devolvido pela mensagem data_set_client.
Data_set_user_interface List
Esta a lista dos objetos de entrada de dados que esto vinculados ao DDO. Este
vnculo pode ser um vnculo de servidor ou de watched-server. Este vnculo no criado
com uma mensagem set-server. O DDO no adiciona o objeto de interface com o
usurio a esta lista at que receba uma mensagem add_user_interface. Essas
conexes podem ser quebradas pela mensagem remove_user_interface. O nmero de
DEOs da lista pode ser consultada com a funo data_set_user_interface_count, e o
ID de um DEO em uma posio particular retornado pela mensagem
data_set_user_interface.
Client_file List
Esta a lista de arquivos filhos que se relacionam ao main_file do DDO (isto , uma
lista de todos os arquivos filhos esperados). Ela no construda automaticamente, mas
sim com mensagens add_client_file que voc deve programar por si mesmo. A lista
deve conter todos os arquivos filhos que estiverem relacionados a esse arquivo.
Atualmente, esta lista utilizada para inibir a excluso se houverem registros filhos. No
futuro, esta lista executar outras tarefas. Os arquivos podem ser removidos desta lista
pela mensagem remove_client_file. O nmero de arquivos da lista pode ser consultado
pela funo child_file_count, e o nmero do arquivo em uma posio particular da lista
pode ser consultado pela funo child_file. Os arquivos filhos so aqueles arquivos que
contm um registro que se relaciona com o registro que ser excludo.

101
U
s
a
n
d
o

D
D
O
s

Server_file List
Esta lista de arquivos para os quais o main_file do DDO deve se relacionar (isto ,
uma lista de todos os arquivos pais esperados). Esta lista no construda
automaticamente, mas sim com mensagens add_server_file que voc deve programar
por si mesmo. A lista no possui um objetivo definido, mas posteriormente, voc estar
bem instrudo para criar e manter esta lista pelo menos para seus novos DDOs. Os
arquivos podem ser removidos desta lista pela mensagem remove_server_file. O
nmero de arquivos da lista pode ser consultado pela funo server_file_count, e o
nmero de um arquivo em uma posio particular da lista pode ser consultado pela
funo server_file.
Parent_file List
Est a lista dos arquivos do banco de dados declarados na clusula updating da
declarao de criao de um objeto DDO. Essa conexo (no recomendada)
estabelecida pela mensagem add_parent_file e removida pela mensagem
remove_parent_file. O nmero de arquivos desta lista pode ser consultado pela funo
parent_file_count, e o nmero do arquivo de uma posio particular da lista
consultada pela funo parent_file.
Cdigo de Exemplo do Dicionrio de Dados
As seguintes definies de dicionrio de dados so fornecidas em disco com a aplicao
de exemplo Order. Elas foram impressas aqui para mostrar a utilizao atual das
caractersticas descritas acima.
Customer.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : CUSTOMER.DD
// Class Name: Customer_DataDictionary
// Revision : 2

Use Windows // Basic Definitions
Use DataDict // DataDictionary Class Definition
Use DDvalTbl // Validation Table Class Definitions


102
U
s
a
n
d
o

D
D
O
s

Open Customer
Open Orderhea
Open Ordsys

//DDB-HeaderEnd
//DDB-SelectionStart
//DDB/ ExternalSelectionList Customer_sl Customer.sl
Register_Object Customer_sl
//DDB-SelectionEnd

Class Customer_DataDictionary is a DataDictionary

//DDB-DefineFieldStart

Set Main_File To Customer.File_Number
Set Cascade_Delete_State To FALSE

Set Foreign_Field_Options DD_KEYFIELD To DD_FINDREQ
Set Foreign_Field_Options DD_INDEXFIELD To DD_NOPUT
Set Foreign_Field_Options DD_DEFAULT To DD_DISPLAYONLY

// Child (Client) file structure................
Send Add_Client_File Orderhea.File_Number

// External (System) file structure.............
Send Add_System_File Ordsys.File_Number DD_LOCK_ON_NEW_SAVE

Define_Auto_Increment Ordsys.Cust_Number To Customer.Number


103
U
s
a
n
d
o

D
D
O
s

// Field-based properties.......................

// Customer.Number
Set Field_Label_Long Field Customer.Number ;
To "Customer Number"
Set Field_Label_Short Field Customer.Number To
"Number"
Set Field_Options Field Customer.Number ;
To DD_AUTOFIND DD_NOPUT
Set Field_Prompt_Object Field Customer.Number ;
To (Customer_sl(Current_Object))
Set Key_Field_State Field Customer.Number To
TRUE
Set Status_Help Field Customer.Number ;
To "Customer Id Number (system assigned)."

// Customer.Name
Set Field_Label_Long Field Customer.Name ;
To "Customer Name"
Set Field_Label_Short Field Customer.Name ;
To "Customer Name"
Set Field_Prompt_Object Field Customer.Name ;
To (Customer_sl(Current_Object))
Set Status_Help Field Customer.Name ;
To "Customer/Company Name."

// Customer.Address
Set Field_Label_Long Field Customer.Address ;
To "Street Address"
Set Field_Label_Short Field Customer.Address To
"Address"
Set Status_Help Field Customer.Address ;
To "Street Address."

104
U
s
a
n
d
o

D
D
O
s

// Customer.City
Set Status_Help Field Customer.City To
"City Name."

// Customer.State
Set Field_Class_Name Field Customer.State To
"dbComboForm"
Set Field_Label_Long Field Customer.State To
"State"
Set Field_Label_Short Field Customer.State To
"St."
Set Field_Options Field Customer.State To
DD_CAPSLOCK
Set Field_Value_Check Field Customer.State ;
To "AK|AL|AR|AZ|CA|CO|CT|DE|FL|GA|HI|IA|ID|IL|IN|KS|KY|;

LA|MA|MD|ME|MI|MN|MO|MS|MT|NC|ND|NE|NH|NJ|NM|NV|NY|OH|OK|OR|PA|RI|SC|;
SD|TN|TX|UT|VA|VT|WA|WI|WV|WY|CN"
Set Status_Help Field Customer.State ;
To "Two-letter state ID."

// Customer.Zip
Set Field_Label_Long Field Customer.Zip ;
To "Zip/Postal Code"
Set Field_Label_Short Field Customer.Zip To
"Zip"
Set Field_Mask Field Customer.Zip To
"#####-####"
Set Field_Mask_Type Field Customer.Zip To
MASK_WINDOW
Set Status_Help Field Customer.Zip ;
To "Zip or Postal Code."

// Customer.Phone_Number
Set Field_Label_Long Field Customer.Phone_Number ;

105
U
s
a
n
d
o

D
D
O
s

To "Phone Number"
Set Field_Label_Short Field Customer.Phone_Number To
"Phone"
Set Status_Help Field Customer.Phone_Number ;
To "Phone Number."

// Customer.Fax_Number
Set Field_Label_Long Field Customer.Fax_Number To
"Fax Number"
Set Field_Label_Short Field Customer.Fax_Number To
"Fax"
Set Status_Help Field Customer.Fax_Number ;
To "Fax Phone Number."

// Customer.Email_Address
Set Field_Label_Long Field Customer.Email_Address;
To "E-Mail Address"
Set Field_Label_Short Field Customer.Email_Address To
"E-Mail"
Set Status_Help Field Customer.Email_Address;
To "E-mail Address (internet)."

// Customer.Credit_Limit
Set Field_Class_Name Field Customer.Credit_Limit To
"dbSpinForm"
Set Field_Mask_Type Field Customer.Credit_Limit ;
To MASK_CURRENCY_WINDOW

// Customer.Purchases
//DDB/ Comment_Short Field Customer.Purchases ;
To "Total Orders. Maintained by OrderHea DD"
Set Field_Label_Long Field Customer.Purchases ;
To "Total Purchases"

106
U
s
a
n
d
o

D
D
O
s

Set Field_Label_Short Field Customer.Purchases To
"Purchases"
Set Field_Mask_Type Field Customer.Purchases ;
Set Field_Options Field Customer.Purchases ;
To DD_DISPLAYONLY

// Customer.Balance
//DDB/ Comment_Short Field Customer.Balance ;
To "Maintained by Orderhea DD"
Set Field_Label_Long Field Customer.Balance To
"Balance Due"
Set Field_Label_Short Field Customer.Balance To
"Balance"
Set Field_Mask_Type Field Customer.Balance ;
Set Field_Options Field Customer.Balance ;
To DD_DISPLAYONLY

// Customer.Comments
Set Status_Help Field Customer.Comments ;
To "Additional Comments and Notes."

//DDB-DefineFieldEnd
End_Procedure // Define_Fields

Procedure Field_defaults
//DDB-FieldDefaultStart
Set Field_Changed_Value Field Customer.State To
"FL"
Set Field_Changed_Value Field Customer.Credit_Limit To
1000
//DDB-FieldDefaultEnd
End_Procedure

107
U
s
a
n
d
o

D
D
O
s

End_Class // Customer_DataDictionary

//DDB-Selection-pkg-Start
Use Customer.sl // Customer_sl
//DDB-Selection-pkg-End
//DDB-FileEnd
Vendor.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : VENDOR.DD
// Class Name: Vendor_DataDictionary
// Revision : 2


Open Vendor
Open Invt
Open Ordsys

//DDB-HeaderEnd
//DDB/ ExternalSelectionList Vendor_sl Vendor.sl
Register_Object Vendor_sl
//DDB-SelectionEnd

Class Vendor_DataDictionary is a DataDictionary

108
U
s
a
n
d
o

D
D
O
s


Set Main_File To Vendor.File_Number


Send Add_Client_File Invt.File_Number

Send Add_System_File Ordsys.File_Number DD_LOCK_ON_NEW_SAVE

Define_Auto_Increment Ordsys.Vendor_Number To Vendor.Id


// Vendor.Id
Set Field_Label_Long Field Vendor.Id To
"Vendor ID"
Set Field_Label_Short Field Vendor.Id To
"Vndr ID"
Set Field_Options Field Vendor.Id ;
To DD_AUTOFIND DD_NOPUT
Set Field_Prompt_Object Field Vendor.Id ;
To (Vendor_sl(Current_Object))
Set Key_Field_State Field Vendor.Id To
TRUE

109
U
s
a
n
d
o

D
D
O
s

Set Status_Help Field Vendor.Id ;
To "Vendor Id Number (system assigned)."

// Vendor.Name
Set Field_Label_Long Field Vendor.Name To
"Vendor Name"
Set Field_Label_Short Field Vendor.Name To
"Name"
Set Field_Prompt_Object Field Vendor.Name ;
To (Vendor_sl(Current_Object))
Set Status_Help Field Vendor.Name ;
To "Vendor Name."

// Vendor.Address
Set Field_Label_Long Field Vendor.Address ;
To "Street Address"
Set Field_Label_Short Field Vendor.Address ;
To "Address"
Set Status_Help Field Vendor.Address ;
To "Street Address."

// Vendor.City
Set Status_Help Field Vendor.City To
"City Name."

// Vendor.State
Set Field_Class_Name Field Vendor.State To
"dbComboForm"
Set Field_Label_Long Field Vendor.State To
"State"
Set Field_Label_Short Field Vendor.State To
"St."
Set Field_Options Field Vendor.State To
DD_CAPSLOCK
Set Field_Value_Check Field Vendor.State ;

110
U
s
a
n
d
o

D
D
O
s

To "AK|AL|AR|AZ|CA|CO|CT|DE|FL|GA|HI|IA|ID|IL|IN|KS|KY|LA;
|MA|MD|ME|MI|MN|MO|MS|MT|NC|ND|NE|NH|NJ|NM|NV|NY|OH|OK|;
OR|PA|RI|SC|SD|TN|TX|UT|VA|VT|WA|WI|WV|WY|CN"
Set Status_Help Field Vendor.State ;
To "Two letter state ID."

// Vendor.Zip
Set Field_Label_Long Field Vendor.Zip ;
To "Zip/Postal Code"
Set Field_Label_Short Field Vendor.Zip To
"Zip"
Set Field_Mask Field Vendor.Zip To
"#####-####"
Set Field_Mask_Type Field Vendor.Zip To
MASK_WINDOW
Set Status_Help Field Vendor.Zip ;
To "Zip or Postal Code."

// Vendor.Phone_Number
Set Field_Label_Long Field Vendor.Phone_Number ;
To "Phone Number"
Set Field_Label_Short Field Vendor.Phone_Number To
"Phone"
Set Status_Help Field Vendor.Phone_Number ;
To "Phone Number."

// Vendor.Fax_Number
Set Field_Label_Long Field Vendor.Fax_Number To
"Fax Number"
Set Field_Label_Short Field Vendor.Fax_Number To
"Fax"
Set Status_Help Field Vendor.Fax_Number ;
To "Fax Phone Number."


111
U
s
a
n
d
o

D
D
O
s



// Field_Defaults:
// This procedure is used to establish default field values.

Forward Send Field_Defaults
End_Procedure // Field_Defaults
End_Class // Vendor_DataDictionary

Use Vendor.sl // Vendor_sl
//DDB-FileEnd
Salesp.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : SALESP.DD
// Class Name: Salesp_DataDictionary
// Revision : 2



112
U
s
a
n
d
o

D
D
O
s

Open Salesp
Open Orderhea

//DDB-HeaderEnd
//DDB/ ExternalSelectionList SalesP_sl SalesP.sl
Register_Object SalesP_sl
//DDB-SelectionEnd

Class Salesp_DataDictionary is a DataDictionary


Set Main_File To Salesp.File_Number

Set Foreign_Field_Options DD_KEYFIELD To DD_NOPUT
DD_FINDREQ

Send Add_Client_File Orderhea.File_Number


// Salesp.Id
//DDB/ Comment_Short Field Salesp.Id ;
To "Unique U/C ascii Id. Assigned by user. "

113
U
s
a
n
d
o

D
D
O
s

Set Field_Label_Long Field Salesp.Id ;
To "Sales Person ID"
Set Field_Label_Short Field Salesp.Id To
"ID"
Set Field_Options Field Salesp.Id ;
To DD_AUTOFIND DD_REQUIRED DD_CAPSLOCK
Set Field_Prompt_Object Field Salesp.Id ;
To (SalesP_sl(Current_Object))
Set Key_Field_State Field Salesp.Id To
TRUE
Set Status_Help Field Salesp.Id ;
To "Sales person ID code - Upper case alpha"

// Salesp.Name
Set Field_Label_Long Field Salesp.Name ;
To "Sales Person Name"
Set Field_Label_Short Field Salesp.Name ;
To "Sales Person Name"
Set Field_Prompt_Object Field Salesp.Name ;
To (SalesP_sl(Current_Object))
Set Status_Help Field Salesp.Name ;
To "Sales person name - first and last"



// Field_Defaults:


114
U
s
a
n
d
o

D
D
O
s

End_Class // Salesp_DataDictionary

Use SalesP.sl // SalesP_sl
//DDB-FileEnd
Invt.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : INVT.DD
// Class Name: Invt_DataDictionary
// Revision : 2


Open Invt
Open Orderdtl
Open Vendor

//DDB-HeaderEnd
//DDB/ ExternalSelectionList Invt_sl Invt.sl
Register_Object Invt_sl
//DDB-SelectionEnd


115
U
s
a
n
d
o

D
D
O
s

Class Invt_DataDictionary is a DataDictionary


Set Main_File To Invt.File_Number


Send Add_Client_File Orderdtl.File_Number

// Parent (Server) file structure...............
Send Add_Server_File Vendor.File_Number


// Invt.Item_Id
Set Field_Label_Long Field Invt.Item_Id ;
To "Invt. Item ID"
Set Field_Label_Short Field Invt.Item_Id To
"Item ID"
Set Field_Options Field Invt.Item_Id ;
To DD_AUTOFIND DD_CAPSLOCK
Set Field_Prompt_Object Field Invt.Item_Id ;
To (Invt_sl(Current_Object))
Set Key_Field_State Field Invt.Item_Id To
TRUE
Set Status_Help Field Invt.Item_Id ;

116
U
s
a
n
d
o

D
D
O
s

To "Inventory Item Id - user defined identification"

// Invt.Description
Set Field_Label_Long Field Invt.Description ;
To "Invt. Description"
Set Field_Label_Short Field Invt.Description To
"Description"
Set Status_Help Field Invt.Description ;
To "Inventory Part Desription"

// Invt.Vendor_Id
Set Field_Options Field Invt.Vendor_Id To
DD_CAPSLOCK
Set Status_Help Field Invt.Vendor_Id ;
To "Vendor Number"

// Invt.Vendor_Part_Id
Set Status_Help Field Invt.Vendor_Part_Id ;
To "Vendor ID name for this item"

// Invt.Unit_Price
Set Field_Mask_Type Field Invt.Unit_Price ;
Set Field_Value_Range Field Invt.Unit_Price ;
To "0" "999999.99"
Set Status_Help Field Invt.Unit_Price ;
To "Retail unit price"

// Invt.On_Hand
//DDB/ Comment_Short Field Invt.On_Hand ;
To "This is adjusted by the OrderDtl DD"
Set Field_Value_Range Field Invt.On_Hand ;
To "-999999" "999999"

117
U
s
a
n
d
o

D
D
O
s

Set Status_Help Field Invt.On_Hand ;
To "Units currently available"


Function Validate_Save Returns integer
Local Integer rVal

Forward Get Validate_Save to rVal
If rval Function_return rval

If Invt.On_Hand lt 0 Begin
Error 300 "Insufficient Inventory stock"
Function_return 1
end
End_function // validate_save

// Field_Defaults:

End_Class // Invt_DataDictionary

Use Invt.sl // Invt_sl

118
U
s
a
n
d
o

D
D
O
s

//DDB-FileEnd
OrderHea.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : ORDERHEA.DD
// Class Name: Orderhea_DataDictionary
// Revision : 2


Open Orderhea
Open Orderdtl
Open Customer
Open Salesp
Open Ordsys

//DDB-HeaderEnd
//DDB-ValidationStart

Register_Object Terms_table
Register_Object Ship_Table

Object Terms_table is a DescriptionValidationTable

Procedure Fill_List
Forward Send Fill_List
Send Add_Table_Value "NONE" "None established"
Send Add_Table_Value "COD" "COD"

119
U
s
a
n
d
o

D
D
O
s

Send Add_Table_Value "NET30" "Net 30"
Send Add_Table_Value "PREPAY" "Pre-payment required"
Send Add_Table_Value "PREPAY" "new terms"
End_Procedure // Fill_List
End_Object // Terms_table

Object Ship_Table is a CodeValidationTable
Set Type_Value To "SHIPPING"
Set Allow_Blank_State To TRUE
End_Object // Ship_Table
//DDB-ValidationEnd
//DDB/ ExternalSelectionList ORDERHEA_SL ORDERHEA.SL
Register_Object ORDERHEA_SL
//DDB-SelectionEnd

Class Orderhea_DataDictionary is a DataDictionary


Set Main_File To Orderhea.File_Number


Send Add_Client_File Orderdtl.File_Number

120
U
s
a
n
d
o

D
D
O
s

Send Add_Server_File Customer.File_Number
Send Add_Server_File Salesp.File_Number

Send Add_System_File Ordsys.File_Number
DD_LOCK_ON_NEW_SAVE_DELETE

Define_Auto_Increment Ordsys.Order_Number To
Orderhea.Order_Number


// Orderhea.Order_Number
Set Field_Options Field Orderhea.Order_Number To
DD_AUTOFIND
Set Field_Prompt_Object Field Orderhea.Order_Number ;
To (ORDERHEA_SL(Current_Object))
Set Key_Field_State Field Orderhea.Order_Number To
TRUE
Set Status_Help Field Orderhea.Order_Number ;
To "Order Number - New orders are assigned numbers
automatically"

// Orderhea.Customer_Number

// Orderhea.Order_Date
Set Field_Class_Name Field Orderhea.Order_Date ;
To "dbSpinForm"
Set Field_Entry_msg Field Orderhea.Order_Date ;
To Entry_Order_Date
Set Field_Mask_Type Field Orderhea.Order_Date ;
To MASK_DATE_WINDOW

121
U
s
a
n
d
o

D
D
O
s

Set Field_Prompt_Object Field Orderhea.Order_Date ;
To (ORDERHEA_SL(Current_Object))
Set Status_Help Field Orderhea.Order_Date ;
To "Date on which the order was placed"

// Orderhea.Terms
Set Field_Class_Name Field Orderhea.Terms To
"dbComboForm"
Set Field_Value_Table Field Orderhea.Terms ;
To (Terms_table(Current_Object))
Set Status_Help Field Orderhea.Terms ;
To "Payment terms"

// Orderhea.Ship_Via
Set Field_Class_Name Field Orderhea.Ship_Via ;
To "dbComboForm"
Set Field_Value_Table Field Orderhea.Ship_Via ;
To (Ship_Table(Current_Object))
Set Status_Help Field Orderhea.Ship_Via ;
To "Shipping method"

// Orderhea.Ordered_By
//DDB/ Comment_Short Field Orderhea.Ordered_By ;
To "This is just a suggested list. No parent files support
this"
Set Status_Help Field Orderhea.Ordered_By ;
To "Order placed by"

// Orderhea.Salesperson_Id
Set Field_Label_Long Field Orderhea.Salesperson_Id;
To "Sales Person Id"
Set Field_Label_Short Field Orderhea.Salesperson_Id;
To "Sales ID"

122
U
s
a
n
d
o

D
D
O
s

Set Status_Help Field Orderhea.Salesperson_Id;
To "Sales Person who initiated the order"

// Orderhea.Order_Total
//DDB/ Comment_Short Field Orderhea.Order_Total ;
To "Maintained by the Orderdtl DD"
Set Field_Mask_Type Field Orderhea.Order_Total ;
Set Field_Options Field Orderhea.Order_Total ;
To DD_DISPLAYONLY

// Orderhea.Last_Detail_Num
//DDB/ Comment_Short Field Orderhea.Last_Detail_Num To
"This is the "sys" counter for order detail. Used/Mainted by OrderDtl
DD"


End_Procedure

// Add a default date if the field is blank
Procedure Entry_Order_Date Integer iField Date dDate
Local Integer Changed
Get Field_Changed_State iField to Changed
If ( Changed=0 AND dDate =0) Begin
SysDate4 dDate
Set Field_Default_Value iField to dDate
End

123
U
s
a
n
d
o

D
D
O
s

End_Procedure

Procedure Update
Forward Send Update
Send Adjust_Balances OrderHea.Order_Total
End_procedure

Procedure Backout
Forward Send Backout
Send Adjust_Balances (-OrderHea.Order_Total)
End_procedure

Procedure Adjust_Balances Number Amt
Add Amt to Customer.purchases
Add Amt to Customer.Balance
End_Procedure

Procedure Deleting
Forward Send Deleting
// see if we can decrement the order number in sys file...can
only do
// this if this is the newest order.
If OrderHea.Order_Number eq OrdSys.Order_Number Begin // if
this is
Decrement OrdSys.Order_Number // the last number,
SaveRecord Ordsys // decrement and
save.
End
End_Procedure

End_Class // Orderhea_DataDictionary


124
U
s
a
n
d
o

D
D
O
s

Use ORDERHEA.SL // ORDERHEA_SL
//DDB-FileEnd
Orderdtl.dd
//DDB-FileStart
//DDB-HeaderStart

// File Name : ORDERDTL.DD
// Class Name: Orderdtl_DataDictionary
// Revision : 2


Open Orderdtl
Open Orderhea
Open Invt

//DDB-HeaderEnd

Class Orderdtl_DataDictionary is a DataDictionary


Set Main_File To Orderdtl.File_Number


125
U
s
a
n
d
o

D
D
O
s


Send Add_Server_File Orderhea.File_Number
Send Add_Server_File Invt.File_Number

Define_Auto_Increment Orderhea.Last_Detail_Num To
Orderdtl.Detail_Number


// Orderdtl.Order_Number
//DDB/ Comment_Short Field Orderdtl.Order_Number ;
To "Relates to OrderHea DD"
Set Field_Options Field Orderdtl.Order_Number To
DD_NOPUT

// Orderdtl.Detail_Number
//DDB/ Comment_Short Field Orderdtl.Detail_Number ;
To "This is maintained internally and is normally not
displayed"
Set Field_Options Field Orderdtl.Detail_Number To
DD_NOPUT

// Orderdtl.Item_Id
//DDB/ Comment_Short Field Orderdtl.Item_Id ;
To "relates to Invt DD"

// Orderdtl.Qty_Ordered
Set Field_Exit_msg Field Orderdtl.Qty_Ordered ;
To Adjust_Display_Total
Set Field_Label_Long Field Orderdtl.Qty_Ordered ;
To "Quantity Ordered"

126
U
s
a
n
d
o

D
D
O
s

Set Field_Label_Short Field Orderdtl.Qty_Ordered To
"Quantity"
Set Field_Mask_Type Field Orderdtl.Qty_Ordered ;
To MASK_NUMERIC_WINDOW
Set Status_Help Field Orderdtl.Qty_Ordered ;
To "Number of items ordered"

// Orderdtl.Price
//DDB/ Comment_Short Field Orderdtl.Price ;
To "Default is set from Invt. Can be adjusted for each
order."
Set Field_Entry_msg Field Orderdtl.Price ;
To Entering_Price
Set Field_Exit_msg Field Orderdtl.Price ;
To Adjust_Display_Total
Set Field_Label_Long Field Orderdtl.Price ;
To "Price per Unit"
Set Field_Label_Short Field Orderdtl.Price To
"Price"
Set Field_Mask_Type Field Orderdtl.Price ;
Set Status_Help Field Orderdtl.Price ;
To "Price per Unit"

// Orderdtl.Extended_Price
//DDB/ Comment_Short Field Orderdtl.Extended_Price;
To "system maintained: Ext Price = Qty * Price"
Set Field_Label_Long Field Orderdtl.Extended_Price;
To "Extended Price"
Set Field_Label_Short Field Orderdtl.Extended_Price;
To "Total"
Set Field_Mask_Type Field Orderdtl.Extended_Price;

127
U
s
a
n
d
o

D
D
O
s

Set Field_Options Field Orderdtl.Extended_Price;
To DD_DISPLAYONLY
Set Status_Help Field Orderdtl.Extended_Price;
To "Total extended price"


// Update and Backout need to adjust the Invt.On_Hand quantity,
// the dtl line's extended price and the OrderHea total. We will
call
// the same procedure (Adjust_Balances) to insure that backout and
// update are inverses of each other.
// Note that Backout does not need to change the extended_price.
This
// only gets changed as part of update.
Procedure Update
Forward Send Update
Move (OrderDtl.Price * OrderDtl.Qty_Ordered) to
OrderDtl.Extended_Price
Send Adjust_Balances OrderDtl.Qty_Ordered
OrderDtl.Extended_Price
End_Procedure

Procedure Backout
Forward Send Backout
Send Adjust_Balances (-OrderDtl.Qty_Ordered) (-
OrderDtl.Extended_Price)
End_Procedure

// Called by Backout and Update passing the quantity
// and the extended price.
// Subtract quantity from Invt on-hand and
// add extended amnt to order total.

128
U
s
a
n
d
o

D
D
O
s

Procedure Adjust_Balances Number Qty Number Amt
Subtract Qty from Invt.On_Hand
Add Amt to Orderhea.Order_Total
End_Procedure

// when entering the price field we may wish to update the
// current field value with the standard unit price from the
// Invt file. Only do this if the current amount is zero. If non
// zero we assume the field is being edited (and we make no
assumptions).


129
3
B
a
n
c
o

d
e

D
a
d
o
s

Gerenciador de banco de dados Dataflex
O DataFlex foi uma vez classificado com os produtos chamados de sistemas de
gerenciamento de banco de dados (DBMSes). Apesar de ser verdade que o principal
objetivo do DataFlex gerenciar os bancos de dados em disco, as ferramentas do
DataFlex (sua linguagem, ou sistema de desenvolvimento da aplicao) se tornaram to
abrangentes que agora o DBMS apenas uma opo entre os drivers do banco de
dados que podem ser programados para a utilizao pela interface do usurio do
DataFlex. Este captulo fala dessa parte do DataFlexo drive do DataFlex com o qual os
arquivos do banco de dados so criados, modificados, e relacionados entre si.
Os Arquivos de Banco de Dados do DataFlex
Estrutura Lgica de um Arquivo do Banco de Dados
O objetivo dos arquivos do banco de dados registrar a informao no disco e torn-la
acessvel para utilizao atravs de programas. Para facilitar o uso, os dados so
organizados em arquivos, campos, e registros. Um arquivo feito de um nmero varivel
de registros, que possuem a mesma estrutura que formada por campos. Os registros
s diferenciam-se entre si pelos seus contedos. Por isso, os termos estrutura de um
arquivo, estrutura do registro, e estrutura do campo so sinnimos.
A literatura sobre a teoria do banco de dados utiliza alguns sinnimos para esses
termos, o que fornecer boas metforas para descrev-los. Um arquivo do banco de
dados do DataFlex chamada de tabela nessa literatura. Um campo chamado de
coluna, e um registro de linha. Esses termos suportam uma visualizao precisa de
um arquivo de banco de dados
Campos
Este manual tambm utiliza o termo elemento do banco de dados extensivamente
quando se referencia a uma classe de dados distinta de outras (constante, varivel, etc.).
Este termo se refere a um valor, ou a um campo de um arquivo de um registro
particular. O registro particular referido determinado pela ao do programa em tempo
de execuo, mas estes normalmente agem nos elementos do banco de dados em um
registro de cada vez, ao invs de agir no valor do campo de todos os registros de um
arquivo. possvel, alterar o valor de um campo particular em todos os registros com um
programa que passe por todos os registros de um arquivo do banco de dados.
Nos programas, os elementos do banco de dados so referidos em um formato padro
composto do nome do arquivo (DataFlex ou outros DBMS), seguido por um ponto,
seguido pelo nome do campo, como fileName.fieldName. O Campo l ast Name do Arquivo

130
d
o

B
a
n
c
o

d
e

D
a
d
o
s

per son do banco de dados, por exemplo, aparece como per son. l ast Name sempre que
referido em um programa.
Essa nomenclatura binomial dos elementos do banco de dados uma caracterstica da
independncia dos dados do DataFlex em relao aplicao. Essa independncia da
aplicao em relao aos dados refere-se ao fato dos dados poderem existir
independentemente de qualquer programa. Os arquivos do banco de dados no so
definidos, nem modificados em aplicaes, a no ser em situaes excepcionais, pois h
meios de faz-lo.
Preferencialmente, os elementos do banco de dados so referidos em programas por
seus nomes completos, incluindo o nome do arquivo do banco de dados. O nome de
qualquer elemento do banco de dados no varia de um programa para outro, nem seu
tipo ou tamanho.
Os nomes dos campos do DataFlex podem ser qualquer combinao de caracteres, com
at 15 caracteres de comprimento, que devem ser iniciados com uma letra e no devem
conter pontuao que no seja underscore (_).
Os campos do DataFlex podem ser do tipo String, Number, ou Date, alm de outros dois
tipos que no so encontrados em outras classes: Text e Binary. Os primeiros trs tipos
so tipos com tamanhos fixos, e os outros dois possuem tamanho varivel. Para mais
informaes, veja "Campos de Tamanho Varivel".
Assim como no existe como referenciar o valor de um campo em mais de um registro
por vez no DataFlex, no h como referenciar mais de um valor de campo de um certo
registro por vez, a no ser atravs de um tipo de campo especial chamado Overlap.
Para mais informaes, veja Campos Overlap.
Tipos Data em Campos do Banco de Dados
Quando os dados so movidos para um campo, a verificao do tipo do campo
aplicada aos dados, iniciando um erro quando os dados violarem o formato do tipo.
Exemplos seriam mover abc para um campo Number, ou 13/13/13 para uma Data. Os
campos do tipo string e text iro rejeitar quaisquer caracteres que estiverem fora da rea
imprimvel, como as seqncias de controle. Os campos binrios no rejeitam nada.
Os formatos de armazenamento dos tipos de dados no disco tambm variam. Os
Numbers e Dates so armazenados como valores fixos na forma Binary Coded Decimal
(BCD). Os Dates so inteiros julianos e possuem trs bytes de tamanho para todos os
valores.
O formato BCD permite o armazenamento de dois dgitos e um byte de espao no disco
(diferentemente da String, que utiliza um byte por caractere). Um campo Number de trs

131
d
o

B
a
n
c
o

d
e

D
a
d
o
s

bytes pode armazenar valores at 999,999 ou, se houver um ponto decimal, at
99,9999, por exemplo.
Campos de Tamanho Varivel
Os formatos de dados Text e Binary do DataFlex se aplicam exclusivamente aos campos
feitos para armazenar dados ASCII e binary cujo tamanho ultrapassar o mximo de 255
bytes que se aplica aos campos string, variveis, e itens. Por essa razo, esses campos
no podem ser manipulados pelos comandos e funes utilizadas para manipular
campos normais como move, uppercase, trim, calc, e left. Esses campos devem ser
abertos para entrada e sada com os comandos de input e output, e seu contedo deve
ser manipulado como qualquer arquivo seqencial de dados.
A ferramenta para enderear os campos Text e Binary (tamanho varivel) como arquivos
seqenciais o driver dbms: e a opo dbms para os comandos de origem e destino.
Quando o driver dbms: (com dois pontos) for utilizado, o arquivo e o campo devem ser
endereados pelos seus nmeros. Por outro lado, quando a opo do comando (sem os
dois pontos) for utilizada, o arquivo e o campo podem ser especificados no formato usual
fileName.fieldName.
O seguinte programa ir anexar todo o contedo do Arquivo Seqencial WITNESS.EYE
ao Campo account do Arquivo newsEvent do Banco de Dados no registro cujo campo
name tiver o valor Hindenburg:
string transvar 250
open newsevent
direct_input "width: 250: witness.eye"
append_output dbms newsEvent.account
move "Hindenburg" to newsEvent.name
find eq newsEvent.name
[not seqeof] repeat
readln transvar
writeln transvar
[not seqeof] loop
close_input
save newsevent
Uma vez que o comando append_output for utilizado, o material importado dever ser
anexado a qualquer contedo existente do Campo account . A opo de formato width:
est configurada como 250 para fornecer os caracteres de final de linha para o comando
readln que importa os dados seqenciais.

132
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Sadas para arquivos, dispositivos, ou campos abertos com o append_output podem
ser posicionadas no contedo existente com o comando set_channel_position. Onde
necessrio um width: maior que 2048 bytes, o comando set_argument_size pode ser
utilizado para aumentar a capacidade disponvel. Todos os arquivos e campos at o
tamanho configurado podem ser movidos diretamente de um para outro em um nico
comando sem a utilizao de uma varivel intermediria.
Para arquivos binrios, o comando read_block mais apropriado para mover dados. O
programa a seguir ir exportar o valor do Campo 43 do registro cujo campo name tiver o
valor Hyde do Arquivo empl oyee (nmero 16) do Banco de Dados para o Arquivo Grfico
binrio SUSPECT. CUT:
string transvar 250
direct_output "suspect.bmp"
open employee
move "Hyde" to employee.name
find eq employee.name
[found] direct_input "dbms: binary: 16, 43"
[not seqeof] repeat
read_block transvar 250
write transvar
[not seqeof] loop
abort
Quando o arquivo SUSPECT. BMP for aberto com um comando direct_output, qualquer
arquivo existente com esse nome ser excludo antes da sada comear. A referncia
numrica (16, 43) do arquivo e campo no comando direct_input o formato necessrio
onde um driver (neste caso binrio) utilizado. O Dbms tambm utilizado da mesma
forma que um driver (com dois pontos, entre aspas) pela mesma razo.
Os formatos Text e Binary so fornecidos para suportar campos maiores que o limite de
255 bytes aplicado a campos String. Algumas vezes esses tipos so referenciados como
sendo de tamanho varivel, fazendo referncia ao tamanho que retornado por um
desses campos quando gravado, em um arquivo separado do disco, ou enviado para
um dispositivo como uma impressora. Diferentemente dos campos do tipo String, eles
no colocam espaos em branco para preencher seu contedo at o tamanho mximo.
Eles executam isso atravs da manuteno, quando esto comprimidos, de dois bytes
no comeo de cada campo que indica o tamanho do dado em bytes. Devido esse
header, a quantidade de bytes que um campo Binary ou Text pode armazenar dois

133
d
o

B
a
n
c
o

d
e

D
a
d
o
s

bytes menor que seu tamanho declarado. Por exemplo, um campo Binary declarado com
um tamanho de 1024 s poder armazenar 1022 bytes de dados.
No disco, no entanto, os campos Text e Binary ocupam todo o tamanho declarado, a
no ser que voc utilize a compresso de dados para o arquivo. Por essa razo, a
utilizao da compresso praticamente obrigatria para arquivos que contm esses
campos. Alm disso, quando um arquivo que contiver um campo de um desses tipos for
aberto, o buffer do registro para o arquivo consumir memria para o tamanho declarado
dos campos, o que um fator srio sob situaes com memria limitada e muitos
campos grandes.
Campos Overlap
O ltimo tipo de campo o Overlap. Este no apenas um tipo de dados, ele mais
do que um campo. um meio de designar uma regio dentro de cada registro que deve
ser manipulada como se fosse um campo. Como os outros tipos de tamanho fixo, os
campos Overlap so definidos em termos de byte inicial e final do campo, mas
diferentemente dos outros tipos, os campos Overlap podem, e devem, abranger campos
existentes.
Os campos Overlap podem circundar um nico campo real, vrios campos reais, parte
de um campo real, ou at partes de dois ou mais campos reais. Visto que qualquer
campo Overlap deve, como qualquer outro campo, ser feito de bytes contnuos, os
campos encapsulados por um Overlap devem ser contnuos na definio do arquivo.
Visto que eles simplesmente fornecem meios de enderear espao que j existe na
definio do arquivo, os campos Overlap no consomem espao no arquivo de dados.
Os campos Overlap possuem muitas utilidades.
Quando voc insere dados em um campo Overlap, ele movido para o banco de dados
da mesma forma que se voc tivesse endereado campos reais. A verificao do tipo
aplicada aos dados de acordo com os tipos dos campos reais. Por essa razo,
recomenda-se que os campos Overlap no encapsulem campos com mais de um tipo,
ou que pelo menos esses campos Overlap no coloquem dados neles.
Um coisa importante a lembrar que quando modificarmos definies de arquivos que
possuam campos Overlap as posies do byte dos campos Overlap no mudam
automaticamente quando as alteraes dos tamanhos do campo forem feitas nos
arquivos, o que acontece com as posies do byte de campos reais. Se voc inserir ou
excluir um campo, ou alterar seu tamanho, qualquer campo Overlap que enderea uma
posio nesse campo ou qualquer campo listado depois dele na definio do arquivo
ser alterado. Se quiser que o campo Overlap continue endereando os mesmos
campos do registro, voc ter que corrigir a definio para as posies corretas do byte
para os campos em questo.

134
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Suportando Relacionamentos com Vrios Campos
Algumas vezes um relacionamento de arquivo deve ser baseado em dois ou mais
campos. Mas visto que um relacionamento de arquivo pode, na realidade, ser baseado
em apenas um campo no arquivo filho, ele pode ser baseado em dois ou mais campos
apenas encapsulando-os com um campo Overlap. Ento, o campo Overlap designado
para o relacionamento com o arquivo pai. Os campos do arquivo pai devem ser
semelhantemente encapsulados por um campo Overlap, e o ndice que suporta o
relacionamento deve ser definido no campo Overlap, ao invs de ser nos campos reais
que o forma .
Tornando um Campo Secundrio em Primrio sem Mov-lo
Quando houver dois campos em um arquivo filho relacionando-se com campos em um
arquivo pai, o campo listado primeiro na definio do arquivo filho o que ser utilizado
por um comando relate para procurar o registro pai. O campo listado por ltimo no ser
utilizado pelos relates. Se voc quiser utilizar o campo secundrio como primrio,
poder fazer isso definindo um campo Overlap frente do primrio na lista que enderea
a posio do byte do ltimo campo listado. O relacionamento deve, ento, ser apontado
para o campo Overlap.
Relacionando Um Campo com Mais de um Pai
Se precisar relacionar um campo do arquivo filho com mais de um pai, voc poder faz-
lo definindo "clones" do campo do arquivo filho. Quando criar um campo Overlap que
utilize o mesmo espao do registro que um campo que se relaciona com um arquivo pai,
voc ter os meios de relacionar com um arquivo pai diferente com os mesmos dados.
No entanto, se voc precisar executar um attach no arquivo filho, o campo precisar ser
primeiro atualizado a partir do pai declarado no primeiro campo listado e ento a partir
do pai declarado no ltimo campo listado. Na melhor das hipteses, isso redundante,
por isso se estiver fazendo attaches no arquivo, voc deve ter apenas um pai aberto, ou
arrumar a seqncia dos campos conforme suas necessidades, ou deve assegurar que
os dados dos arquivos pais nunca iro variar de um pai para o outro.
Suportando Mais que Um ndice Principal por Campo
Cada campo s pode ter um ndice Principal. Quando um campo fornece o primeiro
segmento para mais de um ndice, e voc precisar de dois ou mais clones do mesmo
dado para utilizar ndices Principais diferentes, voc poder criar esses campos clones
com um campo Overlap endereando a posio do registro do campo real em questo.
Em seus programas, voc devem escolher quais campos devem ser endereados nos
comandos de acordo com qual ndice Principal voc ir utilizar.

135
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Endereando Campos Parciais atravs de Campos Overlap
Os campos Overlap endereados a uma parte do tamanho de um campo ou campo pode
oferecer uma funcionalidade til. Por exemplo, quando um relatrio tiver que quebrar a
primeira letra de um valor do campo, um campo Overlap poder ser definido no primeiro
caractere do campo, e dever ser declarado na linha de comando report como o campo
onde devero ser executadas as quebras de subtotal. O mesmo campo pode ser
utilizado em cabealhos e rodaps para quebra do subtotal.
Quando uma poro de um campo ou campos for conhecida para fornecer valores
adequados no qual o ndice ser baseado, ela poder ser endereada em um campo
Overlap, e o ndice baseado nele ao invs de se basear em um campo real. Com os
nicos valores encontrados juntando pores contnuas de dois campos, esta tcnica
pode resultar em chaves menores de ndice do que se fossem utilizados campos reais
completos. Menores chaves de ndice no apenas produzem menores arquivos de
ndice, mas tambm resultam numa melhor performance.
Registros
Enquanto os arquivos e campos possuem nomes e nmeros, os registros s possuem
nmeros. Esses nmeros comeam com 1 em todos os arquivos, e progridem sem
buracos at o ltimo registro do arquivo. A excluso de registros em um arquivo pode
criar lacunas aparentes nos nmeros do registro. Os novos registros sempre sero
criados sob os nmeros dos registros excludos, a no ser que no haja nmeros de
registro disponveis ou se a opo Re-Use Deleted Space tiver sido rejeitada na
definio do arquivo do banco de dados. Desta forma, os nmeros do registro indicam a
ordem fsica dos registros do arquivo de dados do disco.
Todo registro de um arquivo do banco de dados possui um valor para cada campo, e
cada campo possui um valor em cada registro. No DataFlex, no h diferena entre um
campo nulo e um vazio. Um registro vazio pode ser criado a partir de um existente,
limpando todos os campos do mesmo.
Um registro sempre procurado atravs de seu nmero, o que um indicador fsico
baseado na distncia do registro a partir do incio dos dados. Em um arquivo de registros
de 20 bytes, o quinto registro comea 100 bytes depois do incio do primeiro registro. Os
arquivos so procurados da mesma maneira. Os arquivos do banco de dados do
DataFlex no possuem delimitadores.
Blocos de Registro
Para facilitar a procura de registros, o DataFlex atribui tamanhos de registro que podem
exceder o tamanho da soma dos campos do arquivo. Por exemplo, em um arquivo cujos
campos tiverem 27 bytes, os registros sero criados a cada 28 bytes, com um byte

136
d
o

B
a
n
c
o

d
e

D
a
d
o
s

indefinido dentro (ou entre) cada registro. Os arquivos cujos campos totalizarem 28
bytes, tero o mesmo tamanho para os registros. Esse fator de blocos aplicado
automaticamente quando um arquivo do banco de dados criado.
Os seguintes tamanhos de registro esto disponveis:
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 28 30 32 34 36
39 42 46 51 56 64 73 85
102 128 170 256 384 512 640 768
O valor do tamanho do bloco ir aumentar em 128 bytes aps 256.
A seguir est uma ilustrao de como os 60 primeiros bytes de dados no disco se
parecero em um arquivo que contm registros cujos campos totalizaram 27 bytes. Visto
que o tamanho de 27 bytes para os campos ir atribuir 28 bytes para o tamanho dos
registros, o ltimo byte de cada registro no ser digitado (nem utilizado). O registro
hipottico feito dos seguintes campos:
a String, 15 bytes
/ Date, 3 bytes
1 Number, 2 bytes
b String, 4 bytes
2 Number, 3 bytes
x indefinido
10 20 30 40 50 60
| | | | | |
aaaaaaaaaaaaaaa///11bbbb222xaaaaaaaaaaaaaaa///11bbbb222xaaaaaaaa
| | |
Registro 1 Registro 2 Registro 3
Arquivos do Diretrio da Base de Dados
O termo arquivo do banco de dados no DataFlex no quer dizer o mesmo que arquivo
do disco nos computadores. Um arquivo do banco de dados do DataFlex um grupo
de arquivos em disco que compartilham um nome comum no diretrio. Os arquivos que
formam um arquivo do banco de dados, so distinguidos por suas extenses, as quais
esto descritas abaixo.

137
d
o

B
a
n
c
o

d
e

D
a
d
o
s

O Arquivo de Dados (*.DAT)
Todo arquivo do banco de dados possui um arquivo cujo nome da forma
fileName.DAT. Geralmente, esse arquivo o maior deles, e contm os dados atuais do
arquivo do banco de dados. Ele contm muito pouco alm de dados. Os arquivos no
contm quaisquer caracteres separando um campo do outro, nem um registro do outro.
Eles tambm no contm os nmeros do registro os registros so encontrados e
identificados pelos nmero de bytes, que a distncia que eles esto em relao ao
incio do arquivo de dados. Os arquivos *.DAT contm uma seo (chamada
cabealho) no incio, identificando o nmero de registros do arquivo, a ordem, tamanho
e tipos dos campos, e assim por diante. Alguns desses dados podem ser considerados
como o Registro 0 do arquivo, mas no podem ser acessado ou exibidos na forma de
dados no registro atual.
Arquivo de Dados Comprimido (*.VLD)
Se for feita compresso em um arquivo de banco de dados, seus dados sero gravados
em um arquivo com extenso .VLD. Quando isso feito, o arquivo .DAT se passar a ter
uma pequena frao de seu tamanho original, e s ir conter indicadores para o arquivo
.VLD. O arquivo .VLD tambm muito menor que o arquivo .DAT era, ou deveria ser,
mesmo somando-se o tamanho do novo e menor arquivo .DAT que usado com a
compresso.
Arquivos de ndice (*.K##)
A grande maioria dos arquivos do banco de dados possuem um ou mais ndices, at o
mximo de 15. Um arquivo do banco de dados que possui um ndice tem um arquivo
cujo nome da forma fileName.K1. Um arquivo que possui dois ndices tem os arquivos
fileName.K1 e fileName.K2, e assim por diante. Esses arquivos contm o valor chave
para o ndice de cada registro junto com o nmero de registro de cada um. Quando um
arquivo do banco de dados possuir muitos ndices sem chaves longas, o tamanho
agregado dos arquivos de ndice poder exceder o do arquivo *.DAT.
Para um ndice ser utilizvel em tempo de execuo, o arquivo *.K## correspondente
deve estar presente. Se um arquivo de ndice estiver em um diretrio que no seja o de
seu arquivo *.DAT, ser feita uma procura nos outros diretrios da chave de registro
Data para encontrar o arquivo. Quando um ndice estiver sendo criado (ou reindexado),
ser criado no diretrio do arquivo *.DAT a no ser que uma verso anterior seja
encontrada em um diretrio Data (diferente).
Arquivo dos Nomes do Campos (*.TAG)
Os nomes dos campos de um arquivo do banco de dados so armazenados em um
arquivo cujo nome da forma fileName.TAG. Esses nomes dos campos so necessrios

138
d
o

B
a
n
c
o

d
e

D
a
d
o
s

para executar o Database Builder e outras ferramentas no arquivo. Este um arquivo
ASCII, e pode ser editado, mas no recomendamos que isso seja feito. Se voc no
quiser que seja possvel a navegao ou modificao de uma arquivo, voc poder
remover seu arquivo *.TAG, pois o gerenciador do banco de dados no precisa dele para
utilizar o arquivo do banco de dados.
Arquivo da Definio do Arquivo (*.FD)
Este arquivo tambm contm uma lista dos campos do arquivo do banco de dados, e o
nome do arquivo do DataFlex (o nome atravs do qual endereado nos programas).
Este arquivo vincula cada nome de cada campo ao nmero do campo da definio do
arquivo do banco de dados, e vincula o nome do DataFlex ao nmero do arquivo do
banco de dados da lista de arquivos do DataFlex. O arquivo s necessrio para a
compilao de programas que endeream o arquivo do banco de dados e, mesmo que
este seja um arquivo ASCII, ele no deve ser modificado por outros meios alm das
ferramentas. Se voc quiser impedir a compilao de todos os programas que utilizem
um arquivo do banco de dados em particular, voc pode remover o arquivo *.FD.
Arquivo de Exibio da Definio (*.DEF)
Todos os arquivos anteriores so criados e mantidos pelo Database Builder
automaticamente. Por outro lado, o arquivo *.DEF no criado nem atualizado
automaticamente e as ferramentas no o utilizam. O arquivo *.DEF um arquivo ASCII
que contm uma exibio em forma de tabela dos nomes, nmero de registros, nmero
mximo de registros, status de multi-usurios, nomes, tamanho e ndice dos campos do
arquivo do banco de dados. Resumindo, ele contm tudo. Quando voc imprime uma
definio de arquivo a partir de uma ferramenta, a impresso coincide exatamente com
este arquivo. Esses arquivos podem ser utilizados para criar exibies da estrutura do
arquivo no disco, e so utilizados pelo comando make_file.
Arquivo de Cabealho (*.HDR)
O Database Builder contm uma opo chamada Header Integrity Checking. Se essa
opo for utilizada em arquivo do banco de dados, haver um arquivo fileName.HDR.
Esse arquivo modificado sempre que um registro excludo ou gravado, ou se a
definio do banco dados for alterada (atravs do Database Builder). Se os dados do
cabealho (contidos no arquivo .DAT) forem corrompidos, o arquivo .HDR necessrio
para restaur-los.
O Filelist
O DataFlex mantm uma lista de arquivos do banco de dados em um arquivo especial
chamado (por padro) FILELIST.CFG. Essa lista de arquivos deve ser encontrada para

139
d
o

B
a
n
c
o

d
e

D
a
d
o
s

executar ou compilar programas do DataFlex que utilizem os arquivos do banco de
dados. Voc pode manter um FILELIST.CFG em qualquer (ou todos) diretrio, com esse
ou qualquer outro nome. O arquivo procurado atravs da chave de registro
FileListPath da aplicao. Voc pode configurar o arquivo que seu programa utiliza
como lista de arquivo utilizando o comando set_filelist, e consult-lo com o get_filelist.
Com esse comando, o nome do arquivo pode ser configurado para qualquer nome
desejado.
A lista de arquivo mantm quatro atributos de um arquivo do banco de dados, so eles: o
nome do arquivo do DataFlex, seu nmero, seu nome de exibio para o usurio, e seu
nome fsico, opcionalmente incluindo o caminho. O seu nome de exibio para o usurio
mostrado no Database Builder e em outras ferramentas, onde ele pode ser modificado.
Visto que esses nomes podem ter at 40 caracteres de comprimento, eles podem e
devem conter uma descrio do objetivo, contedo, e outras informaes pertinentes ao
arquivo.
Geralmente, os programas em execuo acessam arquivos do banco de dados atravs
de seus nmeros na lista. Quando um programa estiver sendo compilado, o compilador
ir procurar a definio do arquivo e o nmero do mesmo no arquivo *.FD do arquivo do
banco de dados, e substituir os nomes do arquivo e dos campo do cdigo fonte pelos
nmeros no arquivo compilado (.VD7). Quando o programa estiver sendo executado,
esses nmeros sero utilizados para procurar os nomes fsicos dos arquivos do banco
de dados da lista de arquivos. Algumas vezes, os nmeros do campo e do arquivo so
utilizados explicitamente no cdigo fonte do DataFlex.
Se a lista de arquivos no tiver o caminho do diretrio de um arquivo do banco de dados,
o runtime ir procurar no(s) diretrio(s) identificados no valor da chave de registro Data
para encontrar o arquivo durante um open.
Se suas necessidades excedem a regio suportada (4096 arquivos) por um simples
filelist, ento voc pode usar mltiplos filelists e ter arquivos abertos concorrentemente
de mais de um filelist. Uma aplicao grande pode ter seu prprio filelist. Porm, se um
programa for executado ou compilado com diferentes filelists que tiverem nomes ou
nmeros conflitantes, podem ocorrer problemas srios.
Mtodos para o Acessar os Arquivos do Banco de Dados
Internamente, o DataFlex utiliza trs nomes diferentes para cada arquivo do banco de
dados, sendo que cada um tem um objetivo diferente.
Path/Rootname do Diretrio
O path/rootname de diretrio de uma arquivo do banco de dados o que o sistema
operacional utiliza para localizar o arquivo fsico que constitui um arquivo do banco de

140
d
o

B
a
n
c
o

d
e

D
a
d
o
s

dados. Se um path/rootname contiver um caminho a partir do diretrio raiz, um comando
de diretrio do sistema operacional dever listar os arquivos. Se o path/rootname do
diretrio s tiver o nome do arquivo comum a todos os arquivos do diretrios de
arquivos, o DataFlex utilizar o valor da chave de registro Data para procurar o arquivo.
Ele ir procurar cada diretrio identificado no valor da chave de registro Data para na
ordem em que foram definidos, at encontrar o arquivo.
Nome do Usurio
Este nome o exibido pelo Database Builder e outros que exibem dados a partir do
filelist. Com uma capacidade de 40 caracteres, ele foi desenvolvido para exibir uma boa
descrio do arquivo, sua utilizao, contedo, criador, proprietrio, ou qualquer outra
informao que possa ajudar os usurios que estiverem procurando por ele. Com o
comando filelist, voc pode exibir esse nome a partir de seus prprios programas.
Se voc iniciar o nome de Usurio com um smbolo (@), ele no ser exibido nas
ferramentas, e no poder ser selecionado.
Nome do DataFlex
Esta forma de nome do arquivo do banco de dados utilizada nos programas, para
comandos como open, close, relate, attach, save, saverecord, clear, e zerofile.
Tambm utilizada com um ponto e nome de campo para enderear elementos do
banco de dados em programas. Ele no precisa ser igual ao rootname, mas a ao
padro do Database builder torn-los iguais a no ser que voc o altere. Com essa
independncia em relao ao rootname, ele independente de sistemas operacionais
que utilizam sintaxes diferentes para os nomes fsicos, preservando a transportabilidade
dos programas do DataFlex.
As Ferramentas do Banco de Dados
Algumas ferramentas do DataFlex so explicitamente orientadas para o DBMS.
O Database Builder
O Database Builder o mtodo preferido para a criao de arquivos de banco de dados
e de dicionrios de dados, antes da utilizao do IDE para criar a interface da aplicao
com o usurio utilizando os arquivos.
O Database Builder oferece os meios para visualizar a estrutura do campo, do ndice, o
nmero de registros, e outros atributos dos arquivos de banco de dados existentes. O
Database Builder mantm todos os arquivos do diretrio que formam um arquivo do
banco de dados, sendo que todos so atualizados automaticamente a no ser os
arquivos *.DEF. Os arquivos *.DEF podem ser criados no Database Builder, e quando

141
d
o

B
a
n
c
o

d
e

D
a
d
o
s

um novo criado, ele sobrepe a verso anterior do mesmo arquivo existente no
diretrio.
Os arquivos do banco de dados podem ser modificados com dados dentro deles, mas
mais rpido e menos provvel de haver erros se estes forem modificados vazios, isto ,
antes de inserir dados neles. Quando o Database Builder chamado para o
reestruturamento de um arquivo com dados dentro, ele ter que converter os dados da
estrutura antiga para a nova, um processo que pode consumir um tempo significativo em
grandes arquivos.
Com o Database Builder, voc pode adicionar ou excluir campos, ou mov-los entre si.
Voc pode inserir novos campos em qualquer lugar. Geralmente, a ordem dos campos
no arquivo no tem importncia, mas algumas vezes pode ter. Voc pode alterar os
tamanhos dos campos, alterar seus tipos e nomes. A alterao do nome de um campo,
ir fazer com que o cdigo fonte que utiliza os nomes que foram alterados fiquem
inutilizveis at que sejam atualizados. Voc pode alterar o tamanho do registro do
arquivo de banco de dados implicitamente, alterando o tamanho agregado de seus
campos, ou explicitamente, alterado com uma entrada direta.
O Database Builder a ferramenta para a definio dos ndices do arquivo do banco de
dados, e qualquer alterao desejada pode ser feita, apesar de que se houverem
alteraes imprprias nos arquivos inter-relacionados, os relacionamentos podem ser
danificados. Os ndices podem ser adicionados, excludos, inseridos, ou alterados
mesmo se so on-line (atualizados em cada alterao no banco de dados) ou batch
(atualizados apenas na Reindexao). Para ndices existente, os segmentos (campos
participantes) podem ser adicionados, inseridos, ou alterados independentemente se
forem ascendentes ou descendentes, ou se forem case-sensitive ou case-insensitive.
Voc pode alterar o nmero mximo de registros que o arquivo do banco de dados pode
armazenar, um fator importante para o desenvolvimento dos arquivos de ndice. Voc
pode atualizar um ou todos os ndices de um arquivo do banco de dados atravs do
Database Builder.
O Database Builder oferece meios para a definio de relacionamentos entre arquivos.
Definio de relacionamento um processo de definio no qual um campo em um
arquivo pai relacionado a um campo no arquivo filho. Essas definies sempre so
feitas no arquivo filho, onde muitos registros podem se relacionar com um nico registro
no arquivo pai (o contrrio no permitido). Para mais informaes, veja
Relacionamentos de Arquivos.
Finalmente, o Database Builder tambm fornece os meios para configurar o tipo de
compresso de dados que deve ser aplicada ao arquivo, e para atualizar essa
compresso nos arquivos cujos contedos tiverem sido alterados substancialmente
desde a ltima vez que foram recomprimidos.

142
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Desenvolvendo e Mantendo os ndices
Cada arquivo de banco de dados do DataFlex pode ter at 15 ndices, que podem ter at
16 segmentos (campos) e chave agregada com at 256 bytes. Os ndices so criados e
modificados no Database Builder. Eles podem ser atualizados atravs do Database
Builder, e tambm podem ser atualizados atravs de programas em execuo utilizando
o comando sort.
Como explicado em "Procurando Registros, os ndices so vitais no apenas para
procurar registros que os usurios pedem, mas tambm para a procura (algumas vezes
internamente, sem exibio) de registros nos arquivos relacionados. Os ndices so
vitais para a implementao de relacionamentos de arquivos. A diferena entre ndices
exclusivos e no- exclusivos tambm discutida aqui, da mesma forma que o significado
de "Main index" em relao a um campo.
ndices Batch vs Online
Sempre que um ndice criado, voc ir decidir se o ndice dever ser "online" ou
"batch. A diferena entre esses dois tipos de ndices tem a ver com quando eles so
atualizados, e esse fator, tem a ver com a maneira que o ndice utilizado, e a
performance de suas aplicaes quandos os registros estiverem sendo adicionados,
editados ou excludos.
Um ndice online atualizado sempre que uma alterao feita em um campo (em
qualquer registro) que faz parte de sua definio. As alteraes do ndice ocorrem
quando novos registros so criados, registros existentes so excludos, ou quando um
ou mais campos que formam um ndice so alterados em um registro existente.
Em aplicaes complexas que utilizam dzias de arquivos relacionados, cada um
contendo milhes de registros que contm vrios ndices online com vrios segmentos e
chaves grandes, as alteraes do banco de dados podem ocasionar uma lentido visvel
para o usurio quando os registros estiverem sendo salvos ou excludos.
Isso pode ser diminudo quando certos ndices forem utilizados apenas em momentos
isolados e previstos alterando-os de online para batch. Os ndices batch s so
atualizados quando o banco de dados reordenado explicitamente atravs do comando
sort, ou atravs do Database Builder.
Um ndice batch poderia ser apropriado em uma situao onde uma vez por ms, uma
lista de nomes, balanos e telefones dos clientes tivesse que ser impressa pelo nmero
de dias de atraso do pagamento. No seria necessrio acessar os registros do cliente
pelo ndice diariamente, mas para o relatrio, o ndice necessrio uma vez por ms.
Se o ndice do nmero de dias de atraso fosse definido no arquivo do banco de dados
como um ndice batch, o programa que imprime o relatrio todo ms poderia conter em

143
d
o

B
a
n
c
o

d
e

D
a
d
o
s

seu topo um comando sort endereando o arquivo cujos ndices batch deveriam ser
atualizados. O programa ir continuar depois do comando para imprimir o relatrio,
provavelmente bloqueando as alteraes ao banco de dados at que seja finalizado.
Se um ndice batch for utilizado sem a atualizao, os registros sero impressos fora de
ordem, os registros recentes sero omitidos e impossveis de encontrar, e as tentativas
de encontrar registros excludos desde a ltima atualizao ir gerar erros. Deve-se
tomar medidas adequadas para prevenir esses eventos quando os ndices batch forem
utilizados.
Segmentos Case-Insensitive e Descendentes
Voc pode designar segmentos individuais de ndices case-insensitive e/ou
descendentes. Os segmentos case-insensitive so de valor especial onde o material
como nomes podem conter variaes de letras maisculas e minsculas desconhecidas
para os usurios que procurarem registros. Se o campo em questo for preenchido em
letra maiscula, em ndices que contm segmentos case-insensitive, a seqncia de
registros no ser afetada. Onde esse atributo no utilizado, a letra maiscula vem
antes da minscula. A seqncia AaBbCcDd, e assim por diante.
Os segmentos do ndice designados como descendentes (o padro ascendente)
tambm podem ser muito teis, mas podem impor certas necessidades na programao.
Por exemplo, quando uma declarao find ... gt executada em um ndice que
contm segmentos descendentes, o gt funciona como um lt em segmentos
descendentes. Quando o valor de incio for movido para o buffer do registro para
configurar um ponto de partida para um loop contendo o comando, ele dever estar na
parte inferior da regio, ao invs de estar no topo como acontece nos ndices padres
(ascendentes).
Se, por exemplo, fosse desejado um relatrio de todas as contas vencidas a mais de 30
dias, e o ndice do nmero de dias vencidos fosse descendente, deveramos comear
com um buffer vazio e utilizar uma declarao find ... ge.
Se o ndice for feito dos nmeros de dias aps o vencimento seguido pelo nome do
cliente, o ge teria efeito de le no primeiro segmento (nmero de dias), e o ltimo registro
do ndice (o maior nmero de dias aps o vencimento) seria encontrado. No prximo
segmento, o nome do cliente, o ge encontraria o primeiro cliente na ordem alfabtica, e
os clientes seriam listados na ordem alfabtica para cada nmero de dias aps o
vencimento. O relatrio iria continuar com um loop contendo find ... gt at que o
valor 30 fosse encontrado como nmero de dias aps o vencimento, e, nesse ponto,
seria finalizado.
Os segmentos de ndice case-insensitive pode reduzir a utilizao da otimizao da
procura, na qual os relatrios podem imprimir valores do ndice ao invs dos valores

144
d
o

B
a
n
c
o

d
e

D
a
d
o
s

atuais do registro. Os valores armazenados nesses segmentos esto em letra
maiscula, e por isso se os valores dos campos tiverem que ser impressos da forma que
foram digitados no banco de dados, o buffer do registro ter que ser carregado para
acessar os valores atuais. A otimizao da procura funciona tornando o carregamento do
buffer do registro desnecessrio. Onde a sada em letras maisculas for aceitvel, no
haver problemas.
Suportando Selees
Se sua aplicao tiver que suportar selees de intervalos de registros compartilhando
um valor, ou um intervalo de valores, voc pode acelerar algumas selees fornecendo
ndices para suport-las. As selees em questo so aquelas nas quais os dados a
serem enviados so todos os dados necessrios para o ndice, ou que possuem poucos
dados que no so utilizados no ndice.
Considere, por exemplo, um relatrio de clientes por pas com os nmeros dos clientes
depois dos nomes deles. Depois suponha que cada vez que o relatrio for executado,
ser apenas para clientes de um pas em particular. O ndice necessrio deve ser
baseado primeiramente no pas, depois no nome do cliente. Se esse ndice for utilizado,
o registro de cada cliente que estiver no critrio deve ser retornado para o buffer do
registro para receber o nmero do cliente. Mas se o ndice tiver o pas, o nome do cliente
e o nmero do cliente, os dados do registro no precisaro ser carregados todo o
relatrio poder ser lido diretamente dos dados do ndice.
Apesar desse tipo de ndice aumentar a velocidade das selees, quanto maiores e mais
complexos os ndices forem, maior o seu custo. Especificamente, as gravaes de
registros novos e editados demoram mais se o ndice for on-line (mas no se for batch).
Procuras individuais feitas pelo usurio tambm podem demorar mais se o ndice
estendido for utilizado para execut-las. Essa desvantagem, se for significante, pode ser
evitada atravs da utilizao dos ndices estendidos apenas para a seleo de relatrios,
e o formato menor do ndice para procuras individuais. Neste caso, mais importante
configurar o ndice estendido para o modo batch, visto que ele constitui um ndice
adicional que seria atualizado em toda a gravao se fosse deixado como online.
Relacionamentos de Arquivos
Os relacionamentos de arquivos so indispensveis para fazer o gerenciamento dos
dados nas aplicaes. Os relacionamentos de arquivos so virtualmente a pedra
fundamental para a prtica moderna de banco de dados, e as aplicaes de banco de
dados que no utilizarem os relacionamentos so rudimentares ou tm um objetivo muito
especfico.

145
d
o

B
a
n
c
o

d
e

D
a
d
o
s

As capacidades relacionais do DataFlex comeam com a habilidade de ter vrios
arquivos do banco de dados abertos para adicionar, alterar, e excluir ao mesmo tempo.
Isso seria suficiente para permitir que voc pudesse criar e manter relacionamentos de
arquivo. Mas o DataFlex tambm suporta os relacionamentos atravs de condies nas
definies do arquivo e vrios comandos relacionais como o relate e attach. Ambos
sero descritos em "Procurando Registros.
A melhor maneira de utilizar o mximo das capacidades relacionais do DataFlex
modelar inteligentemente os fluxos de dados que voc quer automatizar. Isso requer
percepo e entendimento durante a converso dos sistemas manuais, e talvez mais
conhecimento ainda quando for converter de sistemas automatizados no relacionais.
O mecanismo relacional do DataFlex fundamentalmente hierrquico quer dizer, ele
suporta relacionamentos N para 1. Isso significa que, em dois arquivos relacionados,
vrios registros de um arquivo podem se relacionar com um registro no outro arquivo.
Isso tambm significa que um registro do arquivo mais abaixo pode se relacionar com
apenas um registro no arquivo mais acima na cadeia hierrquica. Isso chamado de
relacionamento N para 1.
Neste manual, o arquivo N e seus registros so chamados de filhos, o arquivo 1 e seus
registros so chamados de pais. Apesar de um registro do arquivo filho s poder se
relacionar com um registro no arquivo pai, no h limite terico para o nmero de
arquivos pais que um arquivo filho pode ter (nem para o nmero de arquivos filhos que
um pai pode ter). O mesmo registro de um arquivo filho pode se relacionar com um
registro em cada um dos cinco arquivos pais, se desejado. Essas disposies so
comuns.
Os arquivos pais podem ter pais, e os arquivos filhos podem ter filhos. Enquanto pai e
filho se referem prximagerao, os termos descendente e ancestral so utilizados
para se referir aos arquivos relacionados ao arquivo referncia por um nmero
indeterminado de geraes.
Mecanismos dos Relacionamentos
Os relacionamentos do DataFlex so baseados na manuteno de cada registro filho de
um ou mais valores de campo que satisfaam os valores de campo do registro pai
relacionado. No necessrio que os campos tenham o mesmo nome em ambos os
arquivos, mas til entender como o cdigo do programa funciona para torn-los
semelhantes. Os campos deve, no entanto, ser do mesmo tipo de dados e do
mesmo tamanho em ambos os arquivos.
Se houvesse um arquivo de faturas e um arquivo de clientes, cada fatura deveria se
relacionar com um cliente. Um certo cliente poderia ter vrias faturas, mas cada fatura s
poderia se relacionar com um cliente. Cada registro desse arquivo de fatura deveria

146
d
o

B
a
n
c
o

d
e

D
a
d
o
s

conter um campo para suportar esse relacionamento. Esse campo, cujos dados devem
coincidir com os do campo do registro pai, poderia ser o nmero do cliente, nome do
cliente, ou qualquer outra coisa que identificasse o registro do arquivo de clientes. O
nmero do registro pode satisfazer esse propsito, mas quando os registros so
excludos ou um arquivo do banco de dados fica corrompido, pode ser difcil ou
impossvel restaurar a estrutura original de dados quando os relacionamentos forem
baseados no nmero do registro.
Os valores do registro que estiverem relacionados nos arquivos pais devem ser nicos.
At em aplicaes onde no necessrio encontrar todos os registros filhos que se
relacionam com um pai em particular, muitas vezes necessrio encontrar o registro pai
de um arquivo filho. No caso das faturas, isso seria para adquirir o endereo do cliente,
por exemplo, e talvez o limite de crdito.
Por essa razo, o campo no qual o relacionamento baseado, deve ser indexado no
arquivo pai. Esse ndice deve ser exclusivo, para que os registros filhos s se relacionem
com registro pai. Em alguns casos onde os registros pais no contm um campo nico, o
ndice de relacionamento baseado em combinaes de dois ou mais campos
(overlaps) de ambos os arquivos que produzem valores nicos na combinao. Em
outras situaes, um gerador de nmero de seriais, como o tipo utilizado para os
nmeros da fatura, utilizado para manufaturar dados nicos para os registros pais. Se
o arquivo de fatura possusse um arquivo filho de itens de linha (transaes), a utilizao
do nmero da fatura para identificar os registros pais seria muito provvel.
Alm de fornecer os campos em ambos os arquivos e o ndice no arquivo pai,
necessrio mais um passo para criar um relacionamento entre dois arquivos. Os campos
da definio de arquivo do arquivo filho devem ser declarados como relacionados a seus
campos semelhantes do arquivo pai. Como uma alternativa, o comando set_relate pode
ser executado no arquivo filho. No necessria nenhuma declarao equivalente, no
arquivo pai. Dessa forma, pode-se dizer que os filhos conhecem seus pais, mas os pais
no conhecem seus filhos.
Utilizando Relacionamentos de Arquivo
Uma vez que o mecanismo relacional estiver correto, ele poder ser utilizado nos
programas com o propsito de manuteno do banco de dados ou relatrios.
Neste ponto, deve ser enfatizado que a ferramenta para a manuteno dos
relacionamentos de arquivos a classe DataDictionary. Para mais informaes, veja A
Classe DataDictionary.
Todos os passos anteriores criao de campos, criao do ndice, definio do
relacionamento so necessrios para a utilizao dos relacionamentos de arquivo com
ou sem os objetos de dicionrio de dados (DDOs). A utilizao deles sem os DDOs,

147
d
o

B
a
n
c
o

d
e

D
a
d
o
s

um processo que requer uma compreenso considervel no apenas da teoria
relacional, mas tambm dos mecanismos de manuteno da integridade dos dados em
um ambiente multi-arquivos e multi-usurio.
Sempre que um grupo de arquivos relacionados do banco de dados for utilizado com um
programa, todos os arquivos utilizados devem, primeiro, ser abertos com o comando
open. Geralmente, um programa orientado a um arquivo de banco de dados particular
abre esse arquivo mais alguns ou todos os ancestrais do arquivo. Se um arquivo filho do
arquivo principal for aberto, provavelmente o programa est orientado para esse
arquivo filho, ao invs de estar orientado para o pai. Por exemplo, onde um programa de
fatura enderear um arquivo de faturas e seu arquivo filho de transaes, o arquivo de
transaes deve ser considerado como o arquivo principal do programa, e o arquivo de
fatura e seus irmos e ancestrais, como os arquivos pais.
Quando um novo registro for aberto, ou um registro existente for encontrado no arquivo
principal, o registro pai poder ser encontrado com um comando da forma relate
child_file. Se, por exemplo, voc estivesse em um arquivo de fatura e quisesse verificar
uma fatura existente que voc s conhece pelo nmero, voc poderia inserir o nmero
da fatura em um campo do registro, e o relate no arquivo de clientes (relate invoice)
encontraria o registro do cliente. Esse registro, iria exibir o nome, endereo, balano
atual, e outros dados do cliente que pudessem no estar no registro da fatura.
Se, por outro lado, voc gerou uma nova fatura para um cliente existente, e voc
mantm o nome do cliente em cada registro de fatura para facilitar que os relatrios de
faturas sejam gerados por ordem alfabtica dos nomes do cliente, um attach invoice
iria mover o nome do cliente para o campo do registro da fatura que se relaciona com o
campo do nome do cliente.
Se no for executado nenhum attach e o registro da fatura for gravado, a mesma coisa
acontecer, visto que o comando save executa um attach antes de efetuar a gravao.
O motivo para se inserir um attach em um comando de gravao como esse, no
apenas uma comodidade e um lembrete, isso feito porque os attaches devem ser
feitos antes da gravao. Quanto maior o intervalo entre uma attach e uma gravao,
maior a possibilidade de um campo do registro pai ser alterado por outro usurio, e com
isso os dados do registro do arquivo filho se tornarem obsoletos. Isso prevenido pelo
DataFlex, mas se ocorrer, uma condio de erro, e pode produzir um processamento
elevado.
Relacionamentos Primrios e Secundrios
O exemplo acima de um registro da fatura que contm ambos o nmero e nome do
cliente uma ilustrao de relacionamentos primrio e secundrio entre os mesmos dois
arquivos. O relacionamento primrio (o nmero do cliente) o utilizado pelos relates, e
feito como primrio atravs do posicionamento do campo antes do campo no qual o

148
d
o

B
a
n
c
o

d
e

D
a
d
o
s

relacionamento secundrio baseado. O relate verifica os relacionamentos dos campos
do arquivo filho na ordem em que esto na definio do arquivo, e cada relacionamento
para um arquivo pai em particular ocasiona uma procura no registro do arquivo pai, os
campos adicionais relacionados com o mesmo arquivo no sero utilizados para a
procura.
Existem vrias vantagens para relacionamentos redundantes desse tipo. A mais bvia
que so fornecidas duas maneiras de relacionamento nos arquivos pais (ambos o
nmero e nome do cliente sero necessrios), e os arquivos filhos obtm um modo
adicional de indexao (novamente, ambos o nmero e nome sero importantes). Mas
existem outros benefcios.
Um tem a ver com as alteraes nos valores chaves nos quais o relacionamento
baseado. Se os nomes do cliente puderem mudar de tempos em tempos, e os nmeros
do cliente no puderem serem alterados, os registros do cliente sempre podero ser
encontrados a partir dos registros da fatura baseados no nmero do cliente. Os nomes
dos clientes simplesmente se tornariam dados auxiliares, onde nenhum relacionamento
de arquivo estaria baseado. O objetivo de relacionamentos secundrios seria puramente
suportar attaches, e nunca suportar relates. Utilizado dessa maneira, os dados do
campo secundrio do arquivo pai no teriam que ser exclusivos, e nem teriam que ser
indexados, conforme necessrio nos campos onde os relacionamentos so baseados.
Um tipo de utilizao oposta seria como um backup do campo primrio. Se, por exemplo,
o nmero do registro fosse utilizado para o relacionamento, ele seria o primrio, porque
o nmero do registro sempre o primeiro campo em todo arquivo do banco de dados. O
nmero do registro sempre fornece uma performance relacional melhor. Mas os nmeros
dos registros so frgeis sujeitos a alterao devido corrupo do arquivo ou outros
contratempos. Se os arquivos pai e filho tiverem um campo no qual o relacionamento
secundrio possa ser baseado, esse campo poder ser utilizado para restaurar os
nmero dos registros corrompidos. Para restaur-los, ser necessrio remover a
definio do primrio temporariamente (baseada no Recnum), trazer cada registro do
arquivo filho para o buffer executar um relate no antigo campo secundrio, mover (no
atravs de attach - o relacionamento foi removido temporariamente) o recnum do pai
para o campo apropriado do filho, e regravar o registro filho. Ento, a definio do
relacionamento primrio poder ser restaurado. Para esse tipo de utilizao, o campo
secundrio do pai deve ser mantido como exclusivo, e a manuteno de um ndice
exclusivo online no campo uma boa maneira de faz-lo.

149
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Utilizando o Banco de Dados nos Programas
Grupo de Comandos do Banco de Dados
Os comandos do Banco de Dados fornecem a capacidade de procurar, gravar e excluir
registros nos arquivos do banco de dados, e de manter relacionamentos entre os
registros.
attach file_mode
clear fill_field
close find
constrain is_file_included
constrained_clear open
constrained_find relate
constraint_set save
constraint_validate saverecord
copy_db sort
copy_records vconstrain
declare_datafile vfind
delete zerofile
delete_db
Comandos do Banco de Dados e o Filelist
Os comandos do Banco de Dados utilizam a informao contida no cabealho do
arquivo de dados e na entrada de dados do filelist. O filelist (um arquivo com o nome
padro de FILELIST.CFG) contm o nmero de campos de cada arquivo, tamanho e tipo
do campo, formatao decimal em campos numricos, nome incluindo a referncia do
drive ou subdiretrio, status de multi-usurio, estrutura do ndice chave do arquivo, etc.
Todas as operaes do DataFlex podem observar os valores desses parmetros de
arquivo sempre que necessrio. Isso evita a necessidade de cada programa manter
dados especficos do arquivo e reduz substancialmente o tempo de desenvolvimento da
aplicao.
O comando open a chave entre esses comandos. Nenhum dos outros comandos
podem ser executados em qualquer arquivo que no tenha sido aberto. O comando

150
d
o

B
a
n
c
o

d
e

D
a
d
o
s

file_mode afeta a maneira na qual o arquivo aberto se para apenas um usurio,
somente leitura, ou para acesso de leitura e gravao por mais de um usurio ao mesmo
tempo (o padro). Quando um arquivo tiver recebido o comando close, ele no fica mais
aberto. O comando declare_datafile permite que o cdigo fonte do programa enderece
um arquivo e seus campos acima do ponto do cdigo fonte onde o arquivo est aberto.
Isto permite a otimizao da performance do programa em tempo de execuo.
Muitos dos comandos podem enderear arquivos do banco de dados atravs do nome
do DataFlex ou nmero do arquivo, sendo que ambos so definidos no filelist. O principal
objetivo dessa ferramenta enderear arquivos que no so do Dataflex, que podem
no ter alguns dos componentes no formato padro file.field dos arquivos do DataFlex.
Quando o nome do arquivo conhecido, seu nmero pode ser utilizado por meios mais
fceis. A palavra-chave file_number pode ser utilizada anexada ao filename do
DataFlex com um ponto (.). O nmero do arquivo account s, por exemplo, pode ser
endereado como uma varivel de sistema account s. f i l e_number . Para isso funcionar, o
arquivo dever ter sido declarado com o comando declare_datafile ou aberto em algum
ponto anterior (no cdigo fonte). Ele no precisa ser aberto (pode estar fechado) no
momento da utilizao da varivel de sistema em ambos os casos.
Muitos dos comandos podem agir em at nove arquivos de banco de dados declarados
explicitamente como argumentos (separados por espaos) na linha de comando. Mas
alguns comandos (clear, delete, e saverecord) s afetam os arquivos declarados em
suas linhas de comandos, enquanto os outros (attach, relate, e save) atingem at os
arquivos pais dos arquivos declarados em suas linhas de comando.
Esses comandos restantes so multi-usurios, sujeitos necessidade de que nenhum
arquivo que no esteja aberto seja afetado. O attach e save (que contm um attach)
pega os valores dos campos dos arquivos pais abertos para os campos dos arquivos
declarados na linha de comando, enquanto o relate alcana todos os parentes acima da
rvore, que estiverem abertos, de cada arquivo declarado para procurar um registro em
cada arquivo cujos dados do campo coincidam com os dados dos campos de cada
arquivo filho no qual o relacionamento baseado.
Os comandos de procura e restrio so de dois tipos bsicos: fixos e variveis. Os que
so de tipo varivel possuem nomes comeando com "v." Esses comandos variveis
podem ser direcionados para vrios arquivos de banco de dados selecionados pelos
usurios em tempo de execuo. Os comandos fixos s podem ser utilizados no arquivo
para o qual ele foi programado, utilizando o modo (greater than, less than, equal to, etc.)
programado. Os comandos de restrio fornecem uma fermentada de filtro na qual,
enquanto as restries estiverem agindo, apenas os registros de um arquivo de banco
de dados cujos dados satisfizerem todas as restries sero vistos pelo programa. Isso
pode aumentar significativamente a performance de procuras intensivas nas aplicaes.

151
d
o

B
a
n
c
o

d
e

D
a
d
o
s

A seguir est uma discusso sobre como os comandos desse grupo podem ser
utilizados para manipular o banco de dados de vrias maneiras.
Na maior parte das situaes da vida real, a melhor maneira de utilizar o banco de dados
utilizar mdulos de programa, chamados de views, que podem conter um ou mais
objetos servidores de dados para controlar o acesso ao banco de dados, e um ou mais
objetos de entrada de dados para fornecer uma interface com os usurios.
Esses objetos distribuem, em seu programa, um sistema sofisticado e abrangente para
vincular o banco de dados a entry forms com vrias procedures internas, incluindo um
conjunto de procedures pr-definidas de teclas aceleradoras. Eles interconectam o buffer
da tela com o buffer do registro de uma forma projetada para manter a integridade dos
dados entre os grupos dos arquivos relacionados.
A dinmica descrita nesta seo representa um subconjunto do que deve ser feito por
qualquer programa que utilize o banco de dados. Utilize essa seo para compreender
como os programas utilizam o banco de dados. No suponha como ideal para a
codificao de aplicaes reais, os cdigos bsicos dos exemplos mostrados.
Abrindo os Arquivos do Banco de Dados
Nada pode ser feito com um arquivo do banco de dados antes que este esteja aberto.
Os arquivos do banco de dados so abertos com o comando open. Da mesma forma
que os outros comandos que endeream arquivos do banco de dados, esse comando
utiliza o nome de arquivo do DataFlex.
Buffers do Registro
Quando um arquivo do banco de dados aberto, um buffer estabelecido na memria
contendo espao suficiente para todos os campos de tamanho fixo da definio do
arquivo. O tamanho desse buffer um pouco maior que o tamanho do comprimento do
registro do arquivo, exceto para o caso especial dos arquivos de sistema, o buffer
limpo imediatamente depois de um open.
Um programa DataFlex pode ter centenas de arquivos do banco de dados abertos ao
mesmo temo (se a capacidade de memria do computador permitir), e h tantos buffers
de registros na memria quanto arquivos estiverem abertos, mas cada buffer contm
apenas um registro de seu arquivo. Os buffers podem estar vazios, ou podem conter um
registro, mas no podem conter mais que um por vez.
Quando um buffer de registro est vazio, dizemos que est inativo, mas quando ele
contm um registro existente, ele se torna ativo. Os buffers ativos de registro podem ser
salvos, limpos, excludos, ou desativados (desligados do registro existente do disco)
movendo um valor para o nmero do registro. Se outro registro for movido para um
buffer que contm um registro ativo, ser exibido um erro.

152
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Quando um buffer de registro estiver ativo, o status do arquivo true, e quando o buffer
estiver inativo, o status false. Cada arquivo aberto possui seu prprio status, e pode
ser consultado, sem ligao com as procuras que forem feitas em outros arquivos. Veja
a Referncia de Comandos mais informaes sobre o Componente Status de Comando.
Arquivos de Sistema
Um arquivo que definido para ter no mximo um registro tambm chamado de
arquivo do sistema diferencia-se dos outros arquivos (multi-registros) no fato de que o
contedo de seu nico registro movido para o buffer do registro imediatamente quando
o arquivo for aberto com o comando open. Um arquivo de sistema pode ser visualizado
como um conjunto de arrays no disco, e ao contrrio do que o seu nome possa parecer,
o DataFlex no limitado a apenas um desses arquivos por computador, ou at por
diretrio. Voc pode ter tantos arquivos de sistema quanto arquivos de banco de dados.
E os arquivos de sistema podem ter vrios campos como qualquer outro arquivo.
Os arquivos de sistema so teis para os dados que pertencem a um lugar, ou at a
uma aplicao. comum, por exemplo, a utilizao com uma entidade (geralmente uma
companhia) com o objetivo de manter seu nome, endereo, e nmero de telefone em um
arquivo de sistema para a utilizao nas aplicaes. Tambm comum a uma aplicao
depender de um arquivo de sistema para armazenar o ltimo nmero da fatura para uma
aplicao na qual vrios usurios possam criar novas faturas em um nico arquivo de
transao ao mesmo tempo.
Em qualquer um dos casos, visto que os arquivos de sistema s possuem um registro,
no h procura nesses arquivos, e no h confuso em qual registro ser necessrio
quando o arquivo for aberto. Por isso, quando esse arquivo for aberto, os dados de seu
nico registro sero movidos automaticamente para seu buffer.
Uma definio de arquivo de sistema com a limitao de um registro, no impede que
sejam adicionados outros registros ao arquivo. Se seu programa no impedir a adio de
registros ao arquivos, os usurios podero, eventualmente, adicionar registros ao
arquivo. Se o arquivo tiver mais que um registro, ele no se comportar da maneira
descrita acima, e sim como um arquivo normal, onde uma procura necessria para
preencher o buffer do registro.
Procurando Registros
A no ser pelo primeiro e ltimo registro de um arquivo do banco de dados (ou ndice),
os registros so encontrados atravs da movimentao de um valor ou valores de
procura para o campo apropriado do buffer de registro do arquivo. O buffer de registro
estabelecido quando um comando open executado no arquivo do banco de dados.

153
d
o

B
a
n
c
o

d
e

D
a
d
o
s

O primeiro registro de um arquivo pode ser encontrado a partir de um buffer vazio
executando um comando find em seu nmero de registro com o operador de
comparao ge (maior ou igual a). O ltimo registro de um arquivo pode ser encontrado
atravs da execuo de um find le by recnum em um buffer vazio (aberto
recentemente ou limpo). O primeiro registro de um ndice pode ser encontrado a partir de
um buffer vazio executando-se um find ge atravs do ndice desejado, ou no campo cujo
ndice principal o ndice desejado. O ltimo registro de um ndice pode ser encontrado
com o find le atravs do ndice ou campo. Em buffers vazios, o ge fornece o mesmo
resultado que o gt, e o le o mesmo resultado que o as lt.
Os registros que no so o primeiro ou o ltimo so encontrados atravs da
movimentao do valor chave do registro desejado para o campo apropriado do buffer
do registro e ento se executando um find com o operador de comparao apropriado
(eq para o valor igual, ge para o valor igual se existir, ou para o prximo registro se no
existir, gt para o prximo registro aps o valor chave, lt para o registro anterior, ou o le).
open villains
move "Jekyll" to villains.alias
find eq villains.alias
Neste exemplo, o arquivo vi l l ai ns utilizado para procurar pelo registro cujo Campo
al i as possua o valor Jekyll. Se nenhum registro possuir um valor igual no campo, o
Indicador found pr-definido configurado para false.
Procurando pelo Nmero do Registro (recnum)
Qualquer registro de um arquivo do banco de dados pode ser encontrado atravs de sua
posio ordinal no arquivo, que um atributo de um registro que pode ser tratado como
se fosse um campo (o primeiro campo, ou o Campo 0), com um nome reservado de
recnum. Em certos casos onde o recnum utilizado como um nmero de srie, ou
onde os relacionamentos de arquivo forem baseados no nmero do registro (ambos no
so recomendados), essa pode ser a maneira apropriada para a procura de registros
especficos. Sempre mais rpida que a procura por um ndice.
A ocasio mais comum para a procura por um nmero de registro quando se atravessa
por todo o arquivo em seu nmero de registro fsico para a elaborao de um relatrio ou
algo semelhante. Se, por exemplo, o total de todos os registros para um certo campo for
necessrio, a maneira apropriada para acumular o total seria executar um find gt ...
by recnum em um buffer vazio, e repetir essa procura em um loop at que nenhum
registro seja encontrado.

154
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Procurando atravs de um ndice
A procura de registro atravs dos valores dos campos de ndice, ou chaves,
semelhante procura de registros atravs do recnum, e a funo mais
freqentemente necessria nas situaes da vida real, especialmente para a procura de
registros especficos (ao invs de navegar por intervalos de registros).
Nas situaes da vida real, os ndices no so compostos por apenas um, mas sim por
vrios campos. Cada campo que participa de um ndice representa um segmento do
ndice. Quando a procura feita atravs dos ndices, essencial que pelo menos o
segmento inicial possua um valor para ser encontrado.
Por exemplo: se um ndice (ndice 1) for formado por dois campos, f i r st Name e
l ast Name, um find gt ... by index.1 depois da movimentao do valor Park para
o Campo l ast Name (e deixando o f i r st Name vazio) ir encontrar o primeiro registro com
um l ast Name, f i r st Name maior que Parko primeiro Park com um f i r st Name que no
estiver vazio, se houver um no arquivo. Se, por outro lado, um comando find eq
command fosse executado sob essas condies, apenas um Park com um f i r st Name
vazio, seria encontrado.
A execuo das mesmas procuras (utilizando o mesmo ndice) com o l ast Name vazio e
um valor no f i r st Name, provavelmente ir gerar um erro. De qualquer forma, o find gt
ir encontrar o primeiro registro do arquivo que tiver um l ast Name que no esteja vazio
(Abernathy), e o find eq ir encontrar o primeiro registro com um l ast Name vazio
provavelmente uma condio ilegal que no existe no arquivo, produzindo uma falha de
procura.
O fill_field move o maior ou menor valor (conforme especificado no comando) possvel
para um tamanho e tipo de campo do registro no buffer do arquivo especificado. Isso
til para procurar o primeiro ou ltimo registro do arquivo pelo ndice baseado no campo,
particularmente de um DBMS que no seja o DataFlex. Visto que ele foi desenvolvido
para a utilizao com campos que podem no ser nativos do DataFlex, o comando
enderea os arquivos e campos pelos seus nmeros, e no pelos nomes.
ndices Exclusivos vs no-Exclusivos
Todos os valores chave de um ndice devem ser nicos. Isso freqentemente desejado
para indexar os registros nos campos cujos valores no podem ser nicos. Os
sobrenomes das pessoas so um bom exemplo disso, e o ltimo e primeiro nomes, em
combinao, das pessoas tambm so um bom exemplo, na maioria dos casos. Onde
um ndice tiver que ser baseado em valores que no so nicos, um elemento nico,
exibido ou no, deve ser adicionado ao ndice e deve ser seu ltimo segmento. A
utilizao do recnum para isso aumenta o nmero de segmentos em uma unidade, mas
consome o menor espao possvel no arquivo de ndice, e resulta no menor custo em

155
d
o

B
a
n
c
o

d
e

D
a
d
o
s

termos de performance. Nesses casos, a sada seqencial de registros chaves sero
pelo nmero do registro, que , arbitrrio na maioria dos casos.
Quando a procura feita atravs de ndices que no so exclusivos, o operado de
comparao eq (igual) nunca virtualmente apropriado, ou efetivo. Continuando com o
exemplo do l ast Name, f i r st Name, o ndice 1 deveria ser feito de um l ast Name,
f i r st Name, e do recnum. Se um find eq fosse executado com o recnum vazio, e s
com o l ast Name e f i r st Name especificados, no seria encontrado nenhum registro,
porque o recnum dos registros que satisfaz essas necessidades dos dois primeiros
segmentos no poderia estar vazio, ou zerado. Por isso, apenas as procuras atravs dos
operadores ge, gt, le, e lt seriam apropriados.
O ndice Principal de um Campo
Quando definir um ndice, indicar para qual campo o ndice o Principal. Essa
designao necessria para as duas situaes onde uma procura no especificada
pelo nmero de um ndice, mas sim pelo nome de um campo. A primeira situao na
qual isso feito quando um comando find programado com a sintaxe find gt| ge|
eq| le| lt df_fileName.fieldName. Para uma procura acontecer nessa situao, o
fieldName dever possuir um ndice Principal da definio df_fileName.
A segunda situao na qual uma procura especificada por um campo ao invs de um
ndice quando uma procura executada atravs da utilizao de uma procedure chave
quando o cursor estiver em uma janela de imagem. Quando a janela est vinculada a um
campo do banco de dados pelo comando entry_item, o DataFlex pode identificar o
campo atravs do qual a procura deve ser conduzida. O ndice Principal desse campo
utilizado. Quando o campo no possuir um ndice Principal, um erro relatado avisando
aos usurios que o campo atravs do qual foi tentada a procura, no possui um ndice.
Isso no significa que o campo no participe de nenhum ndice (ele pode participar de
vrios), mas sim que nenhum ndice Principal foi designado para o campo.
Nenhum campo deve ter mais que um ndice Principal, mas vrios campos podem ter o
mesmo ndice Principal. O ndice l ast Name, f i r st Name pode no ser o ndice Principal
apenas do Campo l ast Name, mas tambm do f i r st Name.
Buferizando ndices
O comando open fornece uma opo para nomear um ndice do arquivo do banco de
dados na linha de comando. Quando um ndice tambm estiver nomeado na linha do
comando open, o ndice ser enviado para o buffer o que significa que blocos do
ndice sero movidos para a memria conforme os registros forem encontrados para que
no seja necessrio o acesso ao arquivo de ndice sempre que outros registros tiverem
que ser encontrados.

156
d
o

B
a
n
c
o

d
e

D
a
d
o
s

open villains by index.1
Neste exemplo, o Arquivo de banco de dados vi l l ai ns aberto com seu ndice 1 no
buffer.
O envio do ndice para o buffer efetivo quando todos (ou as partes principais) os
registros de um arquivo devem ser acessadas em ordem atravs de um ndice, sem
lacunas. Se for utilizado nessas situaes, ele melhora a performance do programa. Se
utilizado em outros momentos, como durante um acesso aleatrio dos registros, ele ir
diminuir a performance, e poder consumir memria sem necessidade. Se utilizado
durante a entrada de dados, ele ir impedir a operao dos ndices online, criando a
aparncia de que eles esto corrompidos.
Imprimindo Dados a partir dos ndices
Aps uma procura em seu programa, apenas os dados do registro que esto contidos no
ndice em utilizao sero acessados, pois o buffer do registro no carregado depois
da procura. Os dados necessrios so impressos a partir do ndice, aumentando
consideravelmente a velocidade de procuras repetitivas. Essas procuras repetitivas
esto envolvidas, por exemplo, em selees a partir do banco de dados, como todos os
representantes de So Paulo, ou todas as placas emitidas no distrito de Minas.
Por padro, o driver do banco de dados do DataFlex s faz isso somente onde nenhum
segmento do ndice designado como case-insensitive. Atravs da utilizao do
comando call_driver, voc pode alterar o valor da varivel FLEX_INDEX_OPT que
possui o padro FLEX_INDEX_OPT_ON. Se voc configur-la para
FLEX_INDEX_OPT_OFF, os dados do ndice nunca sero retornados para o programa;
o buffer do registro ser carregado depois de cada procura. Se voc configur-la para
FLEX_INDEX_OPT_PERMISSIVE, os dados do ndice sero utilizados mesmo se for de
segmentos case-insensitive. Os dados desses segmentos esto em letras maisculas,
que pode diferir dos dados do registros.
Se o programa chamar qualquer dado que no estiver no ndice em utilizao, o buffer
do registro ser carregado e todos os dados viro do prprio registro, ao invs de virem
do ndice.
Procurando atravs dos Relacionamentos
Quando se faz procura ou se cria novos registros em um arquivo que possui um ou mais
arquivos ancestrais, freqentemente desejvel, procurar registros nos arquivos
ancestrais com os quais o registro novo ou existente se relaciona. Por exemplo: um
arquivo de transao sal es pode se relacionar com um arquivo pai par t s, onde o que
est sendo vendido so quantidades do parts, sendo que cada item da linha um
registro do arquivo pai. O arquivo par t s, deve se relacionar com o um arquivo pai

157
d
o

B
a
n
c
o

d
e

D
a
d
o
s

suppl i er . O filho original, sal es, tambm pode se relacionar com um arquivo cust omer ,
contendo registros dos clientes para os quais as parts esto sendo vendidas.
Se todos esses trs ancestrais (dois pais e um av) estivessem abertos pelo comando
open, os registros do part, supplier, e do customer poderiam ser encontrados com um
simples comando relate. O comando relate sales move os registros relacionados
para seus buffers respectivos, desde que o buffer do sal es contenha valores vlidos para
identificar o registro do arquivo part e customer. Evidentemente, depois de procurar no
par t s, seria necessrio que o buffer do mesmo contenha um identificador vlido para o
supplier para que se possa suportar a prxima procura do nvel do av.
O comando relate configura uma srie de procuras em execuo: primeiro dos arquivos
pais abertos, depois dos arquivos avs abertos, e assim por diante at o arquivo
ancestral mais acima da rvore que as definies do arquivo possam alcanar. Se
qualquer arquivo da cadeia no estiver aberto, esta ser quebrada, e o relate da
ramificao onde o arquivo fechado estiver ser interrompido. Visto que freqentemente
esta uma condio proposital, no reportado nenhum erro nessas situaes.
Visto que as procuras feitas nos arquivos ancestrais em um relate so baseadas nos
relacionamentos definidos relativos aos campos, cada campo relacionado em cada
arquivo ancestral deve ter um ndice principal para realizar a procura. Alm disso, os
ndice utilizados com esse objetivo devem ser exclusivos a utilizao de um ndice que
no nico em um relacionamento ir causar ambigidade nos registros dos arquivos
ancestrais que estiverem relacionados atravs de registros nos arquivos descendentes.
O comando attach funciona na direo oposta, e no se envolve na procura.
Normalmente ele utilizado depois de um comando relate. Por exemplo: depois do
comando relate sales, um comando attach sales ir mover os dados dos pais
para seus filhos. O registro par t s, por exemplo, que foi encontrado pelo par t s. number , ir
se mover os dados para o registro sal es como par t s. descr i pt i on e par t s. sel l Pr i ce,
com os campos do sal es para esses itens.
Procurando com Restries
Vrios comandos cujos nomes comeam com constrain so fornecidos para procuras
com restries atravs de um programa ou aplicao para subconjuntos de registros em
um arquivo ou grupo de arquivos relacionados.
O primeiro dos comandos mais importantes o constrain. Com esse comando, voc
pode especificar restries de registros de um ou mais arquivos declarados, para
registros que possuem valores em certos campos em um intervalo particular, ou para
aqueles que se relacionam com qualquer registro especfico de um arquivo pai que
estiver no buffer, ou ainda combinaes lgicas mais complexas que definem o critrio
de seleo.

158
d
o

B
a
n
c
o

d
e

D
a
d
o
s

So necessrios dois passos alm do comando constrain para utilizar o sistema de
restrio. O primeiro utilizar o comando constrained_find para procurar o com
restries, e o segundo controlar os loops da procura de acordo com o estado do
indicador pr-definido found, o que freqentemente feito em qualquer caso com o
comando find padro. Diferentemente do comando find, o constrained_find ir
preencher o buffer com um novo registro mesmo se o found for configurado para false.
O constrained_find configura o found para false no apenas quando o registro no
pode ser encontrado, mas tambm quando um registro for encontrado, mas no
obedecer s restries especificadas.
Existem dois benefcios principais em se utilizar o sistema de restries. O primeiro que
uma maneira conveniente de restringir sistematicamente o acesso aos registros
seletivamente atravs de um programa ou aplicao. O segundo est nos relatrios
onde um ou mais arquivos (ou intervalos entre arquivos) devem ser lidos registro por
registro porque os campos de critrio no esto indexados. Apesar disso poder ser feito
sem o sistema de restrio, mais rpido quando feito com este. Essa leitura de registro
por registro feita com a expresso as expression do constrain. Nesta forma do
comando, expression no pode conter variveis locais; todas as variveis devem ser
globais.
As procuras restringida e regular no impedem a realizao uma da outra em um mesmo
programa. Ambas podem ser utilizadas no mesmo programa sem haver interferncia
entre si.
Durante o desenvolvimento da aplicao, voc pode utilizar dois inteiros pr-definidos
para determinar quantos registros esto sendo testados em uma procura restringida, e
quantos satisfizeram o critrio. Esses inteiros so incrementados continuamente durante
a execuo do programa e devem ser zerados onde voc quiser comear a contagem,
porque seno sero retornados valores incorretos. A constrain_tests_count contm o
nmero de registros testados pelo sistema de restrio, enquanto a
constrain_found_count contm o nmero de registros testados que contm o nmero
de registros que satisfizeram a restrio.
Criando e Alterando Registros
Criando Novos Registros
Imediatamente depois de um comando open, o buffer do registro limpo. Os dados
movidos para o buffer criaro um novo registro no arquivo do banco de dados se este for
gravado. O buffer do registro tambm ser limpo imediatamente aps a execuo de um
comando clear em um arquivo aberto, e novamente um novo registro ser criado na
gravao. Onde voc quiser criar um novo registro com alguns de seus dados de campo
derivados de um registro existente, tudo o que necessrio fazer mover um valor

159
d
o

B
a
n
c
o

d
e

D
a
d
o
s

(recomenda-se 0 para que haja clareza do objetivo) para o recnum do arquivo do banco
de dados antes da gravao. claro que o registro existente deve ser primeiramente
encontrado e movido para o buffer do registro.
Editando Registros Existentes
Quando voc quiser alterar um registro existente, o procedimento muito mais simples.
Simplesmente procure o registro desejado, mova os dados alterados para o buffer, e
grave o buffer alterado. Essa descrio omite as consideraes que so vitais para as
situaes de multi-usurios, onde mais que um usurio pode modificar o mesmo registro
ao mesmo tempo. Nesses casos, essencial reler os dados do registro a partir do disco
imediatamente antes de uma gravao para evitar a sobreposio de alteraes de
outros usurios por dados obsoletos (que voc no alterou) extrados do disco antes que
as alteraes forem gravadas.
As consideraes sobre multi-usurios so citadas em "Consideraes sobre Multi-
Usurios", mas importante lembrar que as caractersticas do ambiente multi-usurio do
DataFlex so completas, bem projetadas, e fceis de serem utilizadas na maioria das
situaes e so virtualmente invisveis. Para mais informaes, veja Grupo de
Comandos Multi-Usurio".
Gravando e Excluindo Registros
Quando h dados no buffer, um comando saverecord ir gravar os dados do buffer de
volta para o registro existente de onde eles foram retirados, ou para um novo registro.
Um comando save, primeiro preenche todos os campos que se relacionam com os
campos dos arquivos pais com os dados dos arquivos pais, e depois executa um
saverecord. Isso equivale a um attach seguido de um saverecord.
O comando delete s opera nos arquivos declarados na linha de comando, e nunca em
ancestrais ou outros arquivos que no foram declarados. Para a excluso funcionar, o
buffer do registro deve conter um registro identificvel, que , um nmero de registro
intacto. Uma excluso executada em um buffer onde isso no verdadeiro, ir gerar um
erro.
Consideraes sobre Multi-Usurios
Quando vrios usurios esto acessando (mais particularmente gravando) o mesmo
banco de dados, essencial que eles no sobreponham o trabalho dos outros. Tambm
necessrio que o trabalho de cada um no seja ignorado pelo sistema, ou que possa
cair em confuses de alguma maneira. Meios de proteo bastante slidos para isso
so fornecidos no DataFlex, e se voc utilizar views construdas apropriadamente, isto ,
contendo objetos de entrada de dados e data set, estes sero automticos.

160
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Os comandos seguintes s funcionaro sob sistemas de runtime multi-usurio. Eles no
surtem efeito em runtimes de um usurio, mas recomenda-se que sejam feitas previses
de multi-usurios em todos os programas para se prevenir caso um programa seja
executado em um ambiente de vrios usurios. Esses comandos so explicados
detalhadamente em "Grupo de Comandos Multi-Usurio".
lock evita que outros usurios travem ou gravem nos arquivos
de dados. O efeito permanece at que o usurio que
executou lock, execute um unlock
reread primeiro executa um lock, depois l os dados de
qualquer arquivo com um buffer de registro ativo.
Utilizado sem um argumento, o reread afeta todos os
arquivos de dados abertos. Como uma alternativa, pode-
se declarar o arquivo que deve ser afetado na linha de
comando do reread
unlock restaura o sistema para o status normal de Read/Write
despool faz com que o spooler de impresso (se houver um) seja
iniciado
O DataFlex manipula a maioria das execues em multi-usurios automaticamente
atravs dos objetos dicionrio de dados (DDOs). No entanto, podem haver casos onde
voc ir querer executar uma operao de E/S no banco de dados cru com comandos
procedurais. Nessas situaes, o DataFlex ajuda voc, reforando as tcnicas de
codificao multi-usurio por todo o programa.
A regra para escrever o cdigo multi-usurio apropriado no DataFlex, nunca executar
edies no banco de dados em uma situao de destravamento. Alm disso, para
assegurar a integridade do banco de dados, deve-se utilizar um reread antes de
quaisquer atualizaes no banco de dados para ter certeza que as alteraes do mesmo
realizadas por todos os usurios so mtuas ao invs de exclusivas.
open vendor
find gt vendor
reread
move "TEST" to vendor.vendor
save vendor
unlock
Este exemplo ilustra a codificao multi-usurio apropriadamente. Se encontrar um
registro, ento executa um reread, que por si executa um lock e ento procura

161
d
o

B
a
n
c
o

d
e

D
a
d
o
s

novamente o registro. Depois disso ele faz a edio (comando move), grava s quando
estiver travado, e destrava quando terminar.
O seguinte exemplo est errado:
open vendor
find gt vendor
save vendor
Neste exemplo, no aplicado nenhum lock (ou reread). Outro usurio pode querer
editar o banco de dados entre o intervalo de uma procura e a gravao. A excluso e
substituio subseqente pode fazer com que o registro incorreto seja editado. Essa
uma possibilidade clara em um local multi-usurio. Se o campo que estiver sendo
editado estiver includo nos ndices, ento estes tambm podem ser corrompidos.
O prximo exemplo tambm est incorreto, por uma razo sutil:
open vendor
find gt vendor
lock
save vendor
unlock
Neste exemplo, executado um lock ao invs de um reread. Aqui, o perigo descrito
acima est restringido por um intervalo muito pequeno entre a procura e o travamento,
mas continua sendo possvel. O reread, que procura novamente o registro, acaba com
essa possibilidade.
No importa o quo rpido seu sistema , sempre haver um curto espao de tempo
entre a procura e o travamento. Ambas as situaes produzem um erro de runtime 4155
Edit requires reread or find during lock (A edio requer um reread ou find durante
o travamento).
O erro 4155 enviado sempre que uma edio ocorrer em um registro existente em um
estado destravado, ou quando o registro for encontrado em um estado destravado e no
for executado um reread. (Observao: o erro no enviado quando for utilizado um
runtime mono-usurio, mas uma boa prtica de programao sempre codificar para
multi-usurio, para haver uma portabilidade mxima). O cdigo a seguir no enviar o
erro:
open vendor
lock

162
d
o

B
a
n
c
o

d
e

D
a
d
o
s

find gt vendor
save vendor
unlock
Neste exemplo, visto que executada uma procura em um estado travado, no
necessrio reread e a edio ocorrer durante o travamento. O cdigo a seguir ir gerar
o erro:
open vendor
lock
find gt vendor
unlock
save vendor
Embora a procura seja executada em um estado de travamento, a edio do buffer do
registro viola a integridade multi-usurio, pois executada em um estado destravado.
O que voc faria se executasse um programa e recebesse essa mensagem de erro?
Voc deveria assegurar-se de, em toda a sua aplicao, sempre seguir as regras da
integridade multi-usurio:
Sempre Executar Edies em um Estado de Travamento
Sempre executar um reread depois de uma procura, ou
Executar a procura em um estado de travamento
E quando h uma situao onde voc possui um processo batch que s executado
noite quando ningum est na rede? E aquele programa de manipulao de dados que
voc escreveu e est executando com dados de teste que ningum est mais utilizando?
O erro 4155 aparecer, mesmo que voc no precise dos resultados do reread e
unlock.
Quando voc tiver certeza que o nico usurio do banco de dados, voc poder
utilizar o atributo df_Filemode df_filemode_single_user. Ele diz ao DataFlex para no
forar as regras de integridade multi-usurio.
O programa abaixo no gera o Erro 4155, porque o atributo file_mode est configurado:
open vendor
set df_filemode vendor df_filemode_single_user
repeat

163
d
o

B
a
n
c
o

d
e

D
a
d
o
s

find gt vendor
[not found] abort
save vendor
loop
Atravs da utilizao do atributo df_Filemode, voc pode modificar programas
existentes que executem edies batch mono-usurio, para que eles no produzam o
Erro 4155.
Grupo de Comandos Multi-Usurio
O DataFlex fornece operaes verdadeiramente multi-usurio. Isso significa que mais
que um usurio pode acessar e alterar o mesmo arquivo do banco de dados
concorrentemente.
despool
lock
reread
unlock
No DataFlex, o arquivo travado apenas durante a gravao. Ento, as atualizaes
so feitas com dados novos e seguros. E apenas os campos que foram alterados so
gravados no registro, preservando quaisquer outras alteraes. Esse tipo de multi-
usurio indetectvel virtualmente pelo operador, em contraste com o tempo de leitura
de um travamento.
As atualizaes de multi-usurios so de dois tipos bsicos: transacionais e de
substituio. As atualizaes transacionais so, geralmente, adies ou subtraes
numricas dos totais em um registro principal. Uma vez que a atualizao for baseada
nos dados de releitura (seguros), as atualizaes de totais sempre sero precisas. As
atualizaes de substituio, (alterar um endereo ou limite de crdito) no requerem a
interao do usurio, mas sim que a aplicao no reescreva arbitrariamente os campos
que no foram alterados, conforme os mtodos tradicionais fazem. O DataFlex fica de
olho nos campos que foram alterados para no reescrever um valor antigo sobre as
alteraes feitas por outro usurio depois da primeira leitura do usurio.
Aqui est um exemplo de com isso funciona:
Trs usurios possuem o item ABC do estoque em suas telas. A quantidade em estoque
(10) e a descrio (WIDGET) so mostradas em cada tela. O usurio 1 est pedindo a
venda de um item, enquanto o 2 est fazendo a venda de 2. O usurio 3 est alterando a

164
d
o

B
a
n
c
o

d
e

D
a
d
o
s

descrio para WIDGET, VERDE. Todos os trs usurios lem suas telas (idnticas),
entram com seus valores, e gravam no mesmo segundo. Digamos que a seqncia atual
de gravaes executa primeiro a gravao no Usurio 1, depois do 2, e por ltimo do 3.
A gravao do usurio 1 ir reler o registro e ver que no foi alterado. Sua venda de um
item ir ser subtrada da quantidade em estoque, e a quantidade em estoque ser
enviada de volta como 9.
Depois a gravao do usurio 2 ir ocorrer, o registro ser relido (9 em estoque), ir
subtrair dois, e a quantidade em estoque passar a ser (7).
A gravao do usurio 3 ser executada, o registro ser relido (com 7 em estoque), s
atualizar a descrio, e a enviar de volta corretamente. Tudo isso ocorre com uma
velocidade que, geralmente, imperceptvel para o usurio.
Nesse sistema, o privilgio de substituio dos campos atualizados transacionalmente
deve ser limitado aos usurios responsveis e bem treinados. Para ter certeza que dois
usurios no vendero quantidades a mais do que h em estoque, o programa dever
verificar a quantia vendida que excede a do estoque, e exibir um erro rejeitando a venda.
As condies anteriores reduzem o tempo de travamento de um sistema ou registro para
um intervalo muito curto necessrio para a gravao de um registro, ao invs da
necessidade de leitura da velocidade da entrada dos operadores. Visto que um campo
no interferem em outro e que as atualizaes transacionais so manipuladas
eficientemente, a declarao o DataFlex fornece proteo transparente de multi-
usurios para o campo totalmente justificada.
Processamento da Transao
O que o Processamento da Transao
O DataFlex suporta o processamento de transao. Uma transao um grupo de
operaes de banco de dados que devem, todas, serem completadas, ou falharem, para
manter a integridade do banco de dados. se uma no puder ser realizada por algum
motivo, ento nenhuma das operaes poder ser completa.
Vamos utilizar o processo de criao de uma fatura como um exemplo. Primeiro voc
dever pegar o ltimo nmero de fatura a partir de um arquivo de sistema, increment-lo,
e escrev-lo de volta. Depois voc dever gravar um registro no arquivo header da
fatura. Depois, para cada item da linha, voc ter que encontrar o registro apropriado no
arquivo de itens, reduzir a quantidade dos itens para refletir a quantidade que est sendo
vendida nesse item da linha e ento gravar um registro no arquivo do item da linha da
fatura. Finalmente, voc dever atualizar o balano do cliente no arquivo de clientes.
Todas as operaes acima formam uma transao.

165
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Vamos supor que durante o processamento de um dos itens da linha da fatura,
descobrimos que parte especificada para o item no est no estoque. O cliente disse
que precisava de todos os itens e no poderia esperar uma encomenda. Por isso,
devemos cancelar a fatura e dizer para o cliente que ele ter que encontrar outra pessoa
para fazer esse pedido.
Sem o processamento de transao, para cada registro do item de linha que j tivesse
sido processado, teramos que procurar o registro correspondente no arquivo de itens,
aumentar a quantidade do item no estoque para refletir a quantidade que est sendo
devolvida ao estoque, e ento excluir o registro do item da linha. Deveramos, ento,
excluir o registro header da fatura. No podemos, no entanto, em um ambiente de multi-
processamento, retornar o nmero da fatura porque algum j pode ter utilizado o
prximo nmero (existem vrias maneiras bem conhecidas de contornar esse problema,
mas para o propsito de nosso exemplo iremos supor que o problema no existe). Esse
processo chamado de "backout. O cdigo que faz isso deve se parecer com o
seguinte:
number amount
integer item_num backout_item
// associa um numeor pare esta nova fatura
reread sysfile
move sysfile.next_invoice to invoice.invoice_number
saverecord invoice
unlock
// Pra cada item da fatura ...
for item_num from 1 to numitems
// Cria um item no arquivo de itens
clear item
: (move os campos do item para a base de dados)
saverecord item

// Atualiza nosso arquivo de estoque para refletir a quantidade
//comprada
move item.stock# to stock.stock#
[not err] begin
find eq stock.stock#


166
d
o

B
a
n
c
o

d
e

D
a
d
o
s

move (stock.available -item.amount) to stock.available
saverecord stock
end

// Atualiza nosso total da fatura para refletir o subtotal dos itens
[not err] begin
move (amount + item.amount) to amount
end

// Se algo errado acontecer, desfaz esta fatura
[err] gosub backout

[not err] loop
// Se nada errado ocorrer, atualiza o total da fatura
if item_num eq numitems begin
reread invoice
move (invoice.amount +amount) to invoice.amount
save invoice
unlock
end
abort
backout:
// Para cada item j salvo para esta fatura ...
for backout_item from 1 to item_num
// Encontrar o item salvo anteriormente
clear item
move invoice.invoice_number to item.invoice_number
move backout_item to item.item#
lock
find eq item.item#

// Atualiza o estoque colocando de volta a quantidade

167
d
o

B
a
n
c
o

d
e

D
a
d
o
s

//comprada para este item
clear stock
move item.stock# to stock.stock#
find eq stock.stock#
move (stock.available +item.amount) to stock.available
save stock
unlock

// Exclui a linha salva
delete item
loop
// Exclui o cabealho da fatura salva
reread invoice
delete invoice
unlock
return
Como voc pode ver, voc ter alguns problemas para retornar a fatura. No entanto, se
utilizar o processamento de transao, existe uma maneira mais fcil. Antes de
escrevermos o primeiro registro, marcamos o incio da transao, executando o
comando begin_transaction. Agora, todas as operaes do banco de dados que
permitem o processamento de transao sero consideradas como uma transao.
Quando tivermos finalizado a ltima operao da transao de forma bem sucedida,
iremos finalizar a transao executando o comando end_transaction. Se quisermos
abortar a transao antes de ser finalizada, podemos executar o comando
abort_transaction. A seguir est o mesmo exemplo, s que este utiliza o
processamento de transao:
// Note que este exemplo no um programa DataFlex completo.
procedure Create_Invoice
local integer InvoiceNum, Item, CustomerNum
local number Amount
move 0 to Amount
:
// Marca o incio da transao
begin_transaction

168
d
o

B
a
n
c
o

d
e

D
a
d
o
s

// Pega o prximo nmero de fatura
move (Get_Invoice_Num(CURRENT_OBJECT)) to InvoiceNum
//escreve o registro do cabealho da fatura
send Write_Invoice_Header InvoiceNum
// Atualiza cada item do registro de itens
for item from 0 to (item_count(CURRENT_OBJECT))
if (Update_Part(InvoiceNum, item)) eq DF_OK;
move (Amount +(Write_Line_Item(InvoiceNum,
item))) to Amount
else ;
// Desfaz a transao
abort_transaction
loop
// Se ns temos todos os itens solicitados, atualiza o
//balano do cliente
if (item = (item_count(CURRENT_OBJECT)));
send Update_Customer CustomerNum Amount
// Finaliza a transao
end_transaction
:
end_procedure
Observe que, a no ser pelo comando abort_transaction, no precisamos mais de
qualquer lgica para desfazer a transao. Quando o abort_transaction for executado,
todos os arquivo do banco de dados incluindo o arquivo de sistema que nos d o nmero
da fatura, sero restaurados para o estado que estavam antes da funo
begin_transaction ser executada.
Depois que uma transao for cancelada, os buffers de todos os arquivos abertos com
um atributo DF_FILE_TRANSACTION configurado como
DF_FILE_TRANSACTION_NONE, sero limpos. Alm disso, se qualquer um deles for
um arquivo de sistema, depois de ser limpo, o primeiro registro ser carregado no buffer.
Apesar do processamento de transao parecer bom, existe uma desvantagem em sua
utilizao. Quando a begin_transaction executado, um travamento executado
automaticamente. O travamento s liberado depois da execuo de end_transaction
ou abort_transaction. Isso significa que o travamento ficar ativo durante toda a

169
d
o

B
a
n
c
o

d
e

D
a
d
o
s

transao. Isso poder causar problemas. Por exemplo: em nosso exemplo, nenhuma
outra fatura poderia ser iniciada at que a nossa estivesse pronta. No entanto, visto que
nenhuma outra fatura poderia ser iniciada, o nmero de uma fatura cancelada poderia
ser restaurado para sua reutilizao.
Tenha em mente que cada arquivo pode ser configurado para permitir ou no permitir o
processamento de transao. Por isso, voc pode controlar quais arquivos iro fazer
parte de uma transao. Apenas os arquivos no sero gravados podero ter o
processamento de transao desligado (por exemplo, arquivos de lookup).
Se voc utilizar comandos de processamento de transao em arquivos que possuem
essa opo desligada, um comando begin_transaction ser equivalente a um lock ou
reread, e um comando end_transaction ser equivalente a um unlock.
Tipos de Processamento de Transao
Existem trs tipos de processamento de transao: client-atomic, server-atomic, e
server-logged. O tipo de transao do arquivo especificado em seu atributo
DF_FILE_TRANSACTION. Nem todos os drivers de banco de dados oferecem os trs
tipos. Os bancos de dados locais do DataFlex (o contrrio dos baseados em servidores)
s oferecem transao client-atomic. Drivers individuais vm com informaes de como
eles manipulam o processamento de transao e outra funcionalidades especfica.
DF_FILE_TRANSACTION_NONE
Os arquivos utilizados apenas para consulta devem ter o processamento de transao
desligado.
DF_FILE_TRANSACTION_CLIENT_ATOMIC
A transaes client-atomic podem ser abortadas pelo programa e, sob algumas
circunstncias (por exemplo, deadlock) elas sero abortadas automaticamente pelo
DataFlex. As transaes client-atomic no fornecem proteo contra travamentos da
estao. Se a estao (por causa de um falha do programa ou do sistema) travar
enquanto uma transao estiver em execuo, parte da transao j ter sido escrita no
banco de dados e no poder ser desfeita automaticamente.
DF_FILE_TRANSACTION_SERVER_ATOMIC
As transaes server-atomic oferecem os mesmos benefcios que as transaes client-
atomic e, alm disso, oferecem a proteo contra travamentos da estao. Se um
programa (ou o sistema) travar enquanto uma transao server-atomic estiver em
execuo, toda a transao pode ser desfeita.

170
d
o

B
a
n
c
o

d
e

D
a
d
o
s

DF_FILE_TRANSACTION_SERVER_LOGGED
A transao server-logged oferece os mesmo benefcios que a server-atomic e, alm
disso, oferece a habilidade de rollback. O rollback do sistema restaura o sistema ao
estado em que se encontrava em um determinado ponto. Por exemplo, se o
processamento de sua folha de pagamento comeou s 13 horase ento algo de errado
aconteceu tarde, voc poder utilizar essa funcionalidade para retornar ao estado que
seu sistema estava s 13 horas, para que possa comear de novo. Observe que todo o
processamento de transao feito depois das 13 horas ser afetado, e no apenas a
folha de pagamento. Esse modo s pode ser utilizado com os arquivo server-based do
banco de dados em uma arquitetura client/server.
Como o Processamento Client-Atomic de Transao Funciona
Uma vez que a funo begin_transaction for executada, todas as alteraes do banco
de dados so registradas em um arquivo virtual de transao. S existem trs operaes
que precisam ser gravadas em um arquivo de transao. Quando voc edita um registro,
o contedo antigo dos campos alterados, o nmero do registro, e o nmero do arquivo
so gravados. Quando voc exclui um registro, todo o registro, o nmero do registro e o
nmero do arquivo sero gravados. E, quando voc gravar um novo registro, o nmero
de registro do mesmo e o nmero do arquivo sero gravados.
Quando a transao finalizada, o contedo atual do arquivo de transao
descartado. O processo de cancelamento da transao mais complicado, mas
basicamente o arquivo de transao lido de trs para frente seqencialmente.
Conforme cada alterao do banco de dados encontrada, a ao apropriada
executada para desfazer a alterao. Registros novos so excludos; registros excludos
so restaurados (com os nmeros de registros originais), e os registros editados
recebem seus valores originais. Por isso, os banco de dados voltam para o estado que
estavam antes da transao. Isso funciona at para bancos de dados que no permitem
a reutilizao de registros excludos. Uma vez que a transao esteja desfeita, o
contedo do arquivo de transao descartado. Se voc finalizar seu programa com
uma transao em andamento, um cancelamento automtico ir ocorrer.
Visto que estamos gravando em um arquivo virtual de transao, o arquivo utilizar a
memria estendida e/ou expandida e o excesso ser escrito no disco. Uma vez que o
arquivo de transao nunca ir nada alm de informaes de transao, mais provvel
que a memria no ser excedida e nenhuma E/S no disco ir ocorrer.
O que o Processamento Client-Atomic de Transao no Faz
Primeiro, o processamento client-atomic de transao no protege o banco de dados de
um travamento. Isso significa que se a transao estiver em progresso e o sistema travar
(talvez por causa de falta de luz) ou se seu programa for finalizado de forma inesperada,

171
d
o

B
a
n
c
o

d
e

D
a
d
o
s

a transao ser parcialmente completada. Voc ter, ento, que consertar
manualmente os arquivos, ou restaur-los a partir de um backup.
Tambm no h proteo para erros de E/S. Se receber um erro de E/S durante uma
operao do banco de dados que for parte de um transao, voc poder tentar cancelar
a transao. No entanto, no h garantias que o cancelamento ir funcionar
corretamente. Tambm possvel receber um erro durante o processo de cancelamento.
Em ambos os casos, o abort_transaction retornar um erro e voc provavelmente
dever restaurar os arquivos a partir de um backup.
Como discutido anteriormente, um travamento est ativo durante uma transao.
Apesar disso evitar que outros processos gravem nos arquivos, isso no impede a
leitura. Isso significa que, da mesma forma que quando no se utiliza o processamento
de transao, outro processo pode ler uma transao parcialmente completa.
Processamento Server-Atomic de Transao
O driver do banco de dados do DataFlex utiliza o NetWare's Transaction Tracking
System para suportar o controle de transao no servidor. Voc deve utilizar um
NetWare shell para poder utilizar essa caracterstica, e o TTS deve estar habilitado em
sua instalao do shell. Os drivers da Microsoft para NetWare no so suportados;
apenas os da Novell. Antes de utilizar o TTS, leia a documentao do TTS da NetWare.
Para ativar o TTS, voc deve configurar a chave TTSPath do registro com todo o
caminho onde os diretrios do TTS do DataFlex Win95/98 e WinNT podem ser
encontrados. Por exemplo:
TTSPath="c:\vdf7\bin\"
Observe que a ltima barra invertida "\" necessria. Quando isso for feito, sua
aplicao, utilizar o TTS automaticamente no Windows 95/98 ou no Windows NT.
O controle de transao server-based permite que uma transao seja completamente
desfeita caso haja uma falha no programa ou na estao onde a transao est sendo
realizada. Isso ocorre automaticamente quando h uma falha. Se essa ferramenta
estiver em uso, no ser necessria nenhuma reindexao aps essa falha. De fato, as
outras estaes, mesmo aquelas com transaes incompletas quando isso ocorrer,
podero continuar as operaes normalmente.
Para a utilizao dessa ferramenta no necessria nenhuma codificao especial no
programa que est sendo executado, a no ser aquelas que so normalmente
necessrias para o controle de transao. No entanto, necessrio configurar o atributo
DF_FILE_TRANSACTION de cada arquivo envolvido para
DF_FILE_TRANSACTION_SERVER_ATOMIC para utiliz-la. Isso pode ser feito em seu
programa ou com o Database Builder.

172
d
o

B
a
n
c
o

d
e

D
a
d
o
s

A configurao de um arquivo server-atomic faz com que o flag de transaction do
NetWare seja configurado nos arquivos .DAT, .VLD, e .K##. Quando uma transao do
DataFlex for iniciada, um incio de transao TTS enviado para cada servidor NetWare
onde cada um desses arquivos residem. No fim da transao, um final de transao TTS
enviado para os mesmos servidores.
Se uma transao do DataFlex ultrapassar o limite de tamanho imposto por sua verso
local do TTS, o administrador do sistema receber um erro do NetWare reportando isso.
No entanto, o programa do DataFlex em si, ir funcionar normalmente, mas sem a
proteo TTS para esta transao.
Se voc tentar excluir um arquivo marcado como TTS atravs do sistema operacional,
essa ao ser interrompida. Voc ter que limpar a marcao com o comando NetWare
FLAG antes que possa ser capaz de executar a excluso. Se voc executar essas
manipulao atravs do DataFlex, a marcao ser limpa conforme for necessrio para
imprimir as operaes desejadas.
Se voc tentar configurar um arquivo que no esteja em um volume TTS NetWare para
server-atomic, o erro 4288 File not on TTS volume ser reportado. Se um programa do
DataFlex abrir um arquivo marcado como TTS que no esteja em um ambiente TTS, o
mesmo erro ser relatado.
Grupo de Comandos do Servidor
Os comandos a seguir executam funes server a partir dos programas do DataFlex:
abort_transaction
begin_transaction
end_transaction
get_transaction_retry
login
logout
set_transaction_retry
Esses comandos podem se comportar diferentemente dependendo do servidor com o
qual eles so utilizados, assim como se forem utilizados sem um servidor.
Comandos que no devem ser Executados em uma Transao
A seguir est uma lista de comandos que causaro um erro se forem executados
enquanto uma transao estiver em progresso:

173
d
o

B
a
n
c
o

d
e

D
a
d
o
s

open
close
login
logout
zerofile
Todas as aes que alteram a estrutura de um arquivo, como a adio ou excluso de
campos, no devem ser realizadas em uma transao. A seguir est uma lista de
comandos que no devem ser executados em uma transao (mas se forem, no iram
gerar erros):
create_field
create_index
delete_field
delete_index
erasefile
sort
structure_abort
structure_copy
structure_end
structure_start
Erros em Transaes
Um bloco lock/reread, unlock, e um bloco begin_transaction, end_transaction
definem um escopo. Para cada begin_transaction deve haver um end_transaction -
seno, ser gerado um erro durante a compilao.
Voc no deve sair do escopo chamando procedures ou funes. O nico mtodo
recomendado para sair de um transao finalizando a declarao (unlock, ou
end_transaction) ou atravs de um comando abort_transaction.
Abaixo est um forma de tratar erros dentro destes blocos:
Lock/Reread
Ocorre um erro (no na transao):
1. Reporta o erro

174
d
o

B
a
n
c
o

d
e

D
a
d
o
s

2. Continua
Ocorre um erro de transao:
1. Verifica a configurao transaction_retry
2. Send verify_retry (para o objeto contendo o lock/reread)
se isto 0: retry (salta para o lock/reread)
se isto no-zero: abort (salta para o unlock)
Unlock

Begin_transaction
Ocorre um erro (no na transao):
1. Salta para end_transaction
2. Aborta a transao, retorna ao estado do incio da
transao
Ocorre um erro de transao:
1. Verifica a configurao transaction_retry
2. Send verify_retry (para o objeto contendo o
begin_transaction)
se isto 0: retry (salta para o begin_transaction)
se isto no-zero: abort (salta para o end_transaction)
End_transaction
Alguns exemplos de erros de transao so: deadlock, can't lock, ou lock timeout. Esses
so erros onde o driver pensa que possui uma chance razovel de funcionar, se tentar
de novo. Essa configurao tambm definvel pelo usurio; quer dizer, voc pode
adicionar erros especficos para configurar os Erros de Transao.
Concluso
O processamento da transao muito fcil de ser implementado. De fato mais fcil
utiliz-lo do que escrever a lgica que pode ser necessria se voc no utiliz-lo.
Apenas lembre-se que o processamento da transao no adequado para todas as
situaes. Analise se o objetivo de sua utilizao para determinar se o processamento
da transao adequado para sua situao particular.

175
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Gerenciando os Arquivos do Banco de Dados em Tempo
de Execuo
Enquanto um programa est sendo executado com arquivos do banco de dados abertos,
possvel alterar o modo de utilizao de um arquivo, consultar os dados sobre seus
campos, ndices, e estrutura bsica, abrir um conjunto alternativo de arquivos, fechar
arquivos, e at criar novos arquivos do banco de dados. possvel manter um arquivo
aberto a partir de um programa para outro.
Conservando Memria e Manipulaes de Arquivos
As tcnicas para conservar memria e ponteiros de arquivos fechando arquivos
abertos ou mudando seus modos tambm pode produzir alguns benefcios na
performance. Quando um reread executado sem nenhum nome de arquivo como
argumento, todos os arquivos abertos do banco de dados no modo padro (multi-user
read/write) so travados e relidos. O fechamento dos arquivos ou a alterao de seus
modos podem reduzir o tempo necessrio para executar esses comandos.
Memria
Quando vrios arquivos do banco de dados esto abertos ao mesmo tempo, seus
buffers podem consumir mais memria que o computador possui. Uma maneira de
recuperar a memria ocupada pelos buffers de arquivo fechar o arquivo do banco de
dados com o comando close. Obviamente, um arquivo que necessrio para edio ou
para fornecer dados relacionais para os arquivos filhos, no devem ser fechados, e
nenhum buffer com registro ativo deve ser fechado. Um arquivo fechado pode ser
reaberto, mas a abertura do arquivo consome um certo tempo, o que tambm acontece
no processo de procura e movimentao de um registro para o buffer.
Os buffers do arquivo consomem memria no que chamado "pilha", que no
desmorona quando um arquivo fechado. Isto , se uma arquivo que no seja o ltimo
que foi aberto, for fechado, seu espao fica disponvel para o prximo arquivo que for
aberto, mas seu espao no ser utilizado por esse arquivo se ele possuir um tamanho
de registro maior que a do arquivo fechado. Isso acontece porque o espao ocupado por
um arquivo fechado permanece restringido pelo outro arquivo que foi aberto aps ele
(enquanto esse estiver aberto). Esse fator pode afetar suas decises sobre a ordem na
qual os arquivos devem ser abertos. Os arquivos que foram abertos mais recentemente,
utilizam o primeiro bloco disponvel de memria contnua que for grande o suficiente
para seus buffers.

176
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Ponteiros de Arquivos
Quando vrios arquivos do banco de dados so abertos para a leitura e gravao em
modo multi-usurio, eles podem, reunidos, consumir mais ponteiros que o sistema
operacional fornece. O fechamento de arquivos, como descrito acima, pode liberar os
manipuladores de arquivos para a reutilizao, mas tambm h uma maneira, que
economiza ponteiros, de alterar o modo de um arquivo enquanto este est aberto.
O comando file_mode oferece dois modos alm do modo padro read/write multi-
usurio para manter um arquivo do banco de dados aberto: read_only e single_user.
Ele tambm oferece um modo default para restaurar arquivos cujos modos foram
alterados de volta para o modo no qual todos os arquivos foram inicialmente abertos.
Quando um modo de arquivo tiver sido configurado para read_only, tentativas de
criao de novos registros, edio de registros, ou excluso de registro, ir gerar erros.
Os erros podem ou no impedir essas alteraes de acordo com o modo que o resto do
programa est escrito, mas as alteraes devem ser impedidas. Da mesma forma,
quando um arquivo est no modo single_user, a utilizao ao mesmo tempo por dois ou
mais usurios pode corromper seriamente os dados do arquivo, por isso devem ser
tomadas medidas apropriadas para assegurar que apenas um usurio por vez possui o
arquivo aberto.
Utilizando o Mesmo Arquivo em Mais de Um Programa
Um programa do DataFlex pode ser executado a partir de outro utilizando-se o comando
chain. Uma opo para esse comando export_files. Quando o export_files
utilizado, todos os buffers que estiverem abertos quando o comando chain for
executado, sero mantidos abertos para o programa seguinte (o qual deve, no entanto,
executar suas prprias aberturas para poder acessar esses buffers). O contedo de
todos os buffers permanece intacto para o programa seguinte, que assume todo o
controle sobre o buffer, inclusive sobre o registro que est nele, se o buffer estiver ativo,
e assim por diante.
Quando o chain utilizado com sua opo wait, a execuo retorna ao primeiro
programa quando o segundo for finalizado. Quando a execuo retorna depois de um
chain wait ... export_files, os buffers esto exatamente no estado em que
foram deixados pelo segundo programa. Essa possibilidade no deve ser ignorada no
planejamento de chamadas de programas. No se deve supor que o mesmo registro
estar no buffer do arquivo, a no ser que o segundo programa no possa alterar o
registro, ou os dados do buffer.

177
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Acessando Filelists
Cada entrada no FILELIST.CFG est associada com um nmero de arquivo (tambm
chamado de file handle) e contm trs nomes associados com o arquivo; o nome de
exibio, o nome lgico e o nome fsico. Esses nomes so acessados pelos atributos
DF_FILE_DISPLAY_NAME, DF_FILE_LOGICAL_NAME e o DF_FILE_ROOT_NAME
respectivamente. Para acessar esses nomes atravs de um nmero de arquivo
especfico, o file handle enviado para a funo get_ ou set_attribute o nmero do
arquivo. A seguir esto alguns exemplo:
// Configura o nome lgico do arquivo 5 para CUSTOMER
set_attribute DF_FILE_LOGICAL_NAME of 5 to "CUSTOMER"
// Pega o nome fsico do arquivo 50
string lpszRootName
get_attribute DF_FILE_ROOT_NAME of 50 to lpszRootName
Tambm h os atributos, DF_FILE_NEXT_USED e DF_FILE_NEXT_EMPTY, para obter
o prximo nmero de arquivo utilizado ou vazio. Ambos os atributos retornam um
nmero de arquivo relativo ao file handle enviado para a funo. Abaixo est um
exemplo da criao de uma nova entrada no FILELIST.CFG para o primeiro nmero de
arquivo que no est sendo utilizado depois do nmero de arquivo 100. Se no
houverem slots vazios maiores que 100, ento o DF_FILE_NEXT_EMPTY ser 0.
integer hFile
// Pega o prximo nmero de arquivo disponvel aps o 100
get_attribute DF_FILE_NEXT_EMPTY of 100 to hfile
if (hfile >0) begin
// Cria uma entrada no FILELIST.CFG
set_attribute DF_FILE_LOGICAL_NAME of hFile to "VENDOR"
set_attribute DF_FILE_ROOT_NAME of hFile to "VENDOR"
set_attribute DF_FILE_DISPLAY_NAME of hFile to "Vendor File"
end
else if (hFile =0)
// No h nmeros de arquivos livres
showln "No empty FILELIST slots."
Criando e Modificando a Estrutura do Arquivo
Com as funes structure_start e structure_end e as funes de atributo, voc pode
criar um arquivo novo ou modificar uma estrutura de arquivo da seguinte forma:

178
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Criando Novos Arquivos
1. Configurao atributos do arquivo
2. Criao de campos e configurao dos atributos do campo
3. Criao de ndices e configurao dos atributos do ndice
4. Executa a structure_end
O exemplo a seguir mostra como criar uma arquivo do banco de dados.
integer File_Number Field_Number handle_number
string Data_File_Name
// Campos usados para exibio da sada
string Field1_Value
integer Field2_Value
date Field3_Value

// O nome do seu arquivo
move "test3" to Data_File_Name
// Chama structure_start colocando o valor do file handle retornado em
// handle_Number
// Inicializando este valor com 0 indica que ns estamos criando um
// novo arquivo
move 0 to handle_Number
// Incio da operao de estrutura. O nome do driver DataFlex
"DATAFLEX"

structure_start handle_number "DATAFLEX"
set_attribute DF_FILE_PHYSICAL_NAME of handle_number to
Data_File_Name
// Cria todos os campos do arquivo.
// O comando create_field sempre insere um campo no arquivo
// especificado pelo nmero do arquivo.

for Field_Number from 1 to 3 begin
create_field handle_number at 0
loop

179
d
o

B
a
n
c
o

d
e

D
a
d
o
s

// Configura os atributos do campo
// Atributos de campo para o campo 1
set_attribute DF_FIELD_NAME of handle_Number 1 to "A1"
set_attribute DF_FIELD_TYPE of handle_Number 1 to DF_TEXT
set_attribute DF_FIELD_LENGTH of handle_Number 1 to 20
set_attribute DF_FIELD_TYPE of handle_Number 2 to DF_BCD
set_attribute DF_FIELD_LENGTH of handle_Number 2 to 12
set_attribute DF_FIELD_TYPE of handle_Number 3 to DF_DATE
// Todas as criaes e modificaes de arquivos comeam com
// structure_start e terminam com structure_end. Este exemplo no
// utiliza uma funo de callback porque o arquivo (novo) no possui
// dados dentro dele.
structure_end handle_Number 0
// Neste ponto, no h entrada no filelist. Os atributos do arquivo
// devem ser configurados para criar uma entrada no filelist.
// A escolha de um nmero do filelist para associar ao seu arquivo de
// dados aleatria. Voc pode associar qualquer nmero que no esteja
// em uso, ou pegar o prximo nmero disponvel usando o seguinte:
get_attribute DF_FILE_NEXT_EMPTY to File_Number
showln "The next available entry in filelist is" " " File_Number
// Configurando os atributos do Arquivo
//
set_attribute DF_FILE_LOGICAL_NAME of File_Number to Data_File_Name
set_attribute DF_FILE_DISPLAY_NAME of File_Number to Data_File_Name
set_attribute DF_FILE_ROOT_NAME of File_Number to Data_File_Name
// O comando structure_end fecha o arquivo de dados. Para modificar ou
configurar valores de campos, voc precisa reabrir o arquivo.
open "test3" as File_Number

180
d
o

B
a
n
c
o

d
e

D
a
d
o
s

showln "Opening file TEST3"
// Criando os arquivos .DEF e .FD
output_aux_file DF_AUX_FILE_DEF for File_Number
output_aux_file DF_AUX_FILE_FD for File_Number
set_Field_Value File_Number 1 to "HELLO"
set_Field_Value File_Number 2 to 200
set_Field_Value File_Number 3 to 12/12/94
saverecord File_Number
// Pegando os valores dos campos e exibindo-os
get_Field_Value File_Number 1 to Field1_Value
showln "The value of Field 1 is " Field1_Value
inkey windowindex // para a execuo at uma tecla ser pressionada
abort

181
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Padres
Quando se cria um arquivo, existem vrios atributos que possuem valores padres.
claro que voc pode mudar esses valores configurando-os manualmente. A tabela a
seguir lista esses valores padres para o driver do banco de dados DataFlex:
ATRIBUTO VALOR PADRO
Integrity Checking DFTRUE
Lock Type DF_LOCK_TYPE_FILE
Maximum Records 10,000
Single/Multiuser DF_FILE_USER_MULTI
Physical Name "dfdeflt"
Reuse Deleted DFTRUE
Transaction Processing DF_FILE_TRANSACTION_CLIENT_ATOMIC
Field Name "FIELDn" (FIELD1, FIELD2, etc.)
Field Length 0
Field Type ASCII
Number of Segments in Index 1
Index Segment Field number 0
Index Segment Features 0
Reestruturando Arquivos Existentes
Para modificar a estrutura de uma arquivo de dados, voc deve iniciar uma operao de
reestruturamento. Isso feito com o comando structure_start. Esse comando recebe o
handle de um arquivo aberto (ou 0 se estiver criando um novo arquivo) e retorna um
handle para a nova estrutura. Voc pode, ento, configurar ou pegar atributos dessa
estrutura, alterar tipos, ndices, segmentos de campo, etc. Outros comandos, como o
create_field e o create_index, permitem que voc adicione novos campos e ndices. A
utilizao do comando set_attribute para modificar qualquer atributo do banco de dados
de um arquivo s pode ser realizada depois que voc tiver executado um
structure_start para o arquivo. voc pode utilizar o set_attribute para modificar os
atributos que no forem do banco de dados, em qualquer momento.
Quando tiver completado suas alteraes, voc deve executar o comando
structure_end, que grava sua nova definio do arquivo, reestruturando e/ou
reindexando o arquivo se necessrio. Uma caracterstica do structure_end sua
habilidade de fornecer informaes de status durante a execuo de operaes de

182
d
o

B
a
n
c
o

d
e

D
a
d
o
s

reestruturamento e de reindexao. Isso feito atravs da utilizao de uma funo de
callback.
Quando executar o structure_end, voc pode, opcionalmente, passar o ID de um objeto
UIMS para ele. Durante a operao de reestruturao ou de reindexao, esse objeto
receber uma mensagem especfica, a get_callback, que uma funo que utiliza um
parmetro String e um Inteiro e retorna um Inteiro. A String o texto que conduz
informaes de status ou uma mensagem de aviso. Integer uma classificao da
mensagem, por exemplo, se for de aviso, o parmetro Inteiro configurado para o valor
constante de df_message_warning. O valor de retorno da get_callback um flag que
diz ao runtime se deve continuar a operao de reestruturamento; se for diferente de
zero, o reestruturamento cancelado.
O que acontece a um arquivo quando voc cancela uma operao de reestruturao ou
de reindexao depois que esta foi iniciada, depende do driver especfico de banco de
dados que est sendo utilizado para acessar o arquivo, podendo resultar em um arquivo
danificado. claro que voc pode cancelar sua operao de reestruturamento antes que
tenha sido iniciada, atravs da execuo do comando structure_abort; isso garante que
seu arquivo ficar intacto.
O comando make_file tambm pode ser utilizado em arquivos existentes que contm
dados. existem vantagens e desvantagens, no entanto, para utilizar o make_file para
reestruturar um arquivo. Para inserir ou excluir campos, voc deve modificar o arquivo
.DEF manualmente, utilizando um editor de texto. Os campos inseridos devem receber
um nmero de campo 0; os campos excludos podem simplesmente ser excludos
do.DEF. A utilizao do make_file dessa maneira oferece um mtodo rpido e fcil para
a modificao de um arquivo; no entanto, a modificao do arquivo .DEF manualmente
deve ser feita com muito cuidado para assegurar que os dados do arquivo .DEF estejam
formatados apropriadamente e que sejam vlidos. Uma vez que esse formato nunca foi
documentado pela Data Access Corporation, voc estar por sua conta e risco quando
executar essa operao. No entanto, se voc precisar produzir rapidamente um
programa que modifique um arquivo, a maneira de fazer essa.
Revisando:
1. Abrir o arquivo existente utilizando o modo de abertura DF_EXCLUSIVE
2. Executar o structure_start
3. Alterar os atributos do arquivo conforme necessrio
4. Criar ou excluir campos e configurar os atributos do campo conforme
necessrio
5. Criar ou excluir ndices e configurar os atributos dos ndices conforme o
necessrio
6. Executar o structure_end

183
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Observao: Se voc alterar a estrutura de um arquivo, quaisquer
constraints anteriores do arquivo no sero vlidas; voc deve reinici-las
depois de uma operao de reestruturamento.
O exempo a seguir mostra como modificar um arquivo existente do banco de
dados. Ele tambm mostra como criar um ndice.
open test3
integer File_Number Field_Number IndexNumber file_handle
// Campos usados para a exibio da sada output
string Field1_Value
integer Field2_Value
date Field3_Value

move test3.File_Number to File_Number
// Digamos que voc queira criar o ndice nmero 2
move 2 to IndexNumber
// Inicia a operao de estrutura
//
move file_number to file_handle
structure_start File_handle "DATAFLEX"
create_index File_handle at IndexNumber
// Isto mostra que o ndice ser baseado em dois campos.
set_attribute DF_INDEX_NUMBER_SEGMENTS of File_handle IndexNumber to
2
// Identifica os campos
set_attribute DF_INDEX_SEGMENT_FIELD of File_handle IndexNumber 1 to
0
set_attribute DF_INDEX_SEGMENT_FIELD of File_handle IndexNumber 2 to
2
structure_end File_handle 0
showln "Index Creation Completed"
open test3
move test3.file_number to File_Number
showln File_Number

184
d
o

B
a
n
c
o

d
e

D
a
d
o
s

//Cria os novos arquivos .DEF e .FD
output_aux_file DF_AUX_FILE_DEF for File_Number
output_aux_file DF_AUX_FILE_FD for File_Number
showln "DEF and FD output completed"
inkey windowindex
abort
Consultando os Atributos do Arquivo
Os atributos do arquivo podem ser lidos com o comando get_attributes. O exemplo a
seguir ilustra como os atributos do arquivo, ndice, e os segmentos do ndice so
consultados para exibio a partir de um programa em execuo que lista os nmeros
dos campos que formam cada ndice de um arquivo do banco de dados chamado
cal or i es:
integer hFile last_index
integer counter index_num num_segs field_num
// Abre CALORIES, e armazena seu nmero no filelist em hFile
move 0 to hFile
open "calories" as hFile
// Pega o nmero do ultimo ndice
// e usa como limitao superior para o loop.
get_attribute DF_FILE_LAST_INDEX_NUMBER of hFile to last_index
for index_num from 1 to last_index
// Para cada ndice, recupera o nmero de segmentos.
get_attribute DF_INDEX_NUMBER_SEGMENTS of hFile index_num to num_segs
show "INDEX " index_num " is based on fields: "
for counter from 1 to num_segs
// Para cada segmento de ndice, recupera o nmero do campo
// utilizado para este segmento
get_attribute DF_INDEX_SEGMENT_FIELD of hFile index_num
counter ;
to field_num

show field_num " "
loop

185
d
o

B
a
n
c
o

d
e

D
a
d
o
s

showln
loop
inkey windowindex
abort
Grupo de Comandos de Estrutura
create_field output_aux_file
create_index set_relate
delete_field structure_abort
delete_index structure_copy
field_map structure_end
load_def structure_start
make_file
O grupo de Estrutura fornece os meios para a criao dos arquivos do banco de dados a
partir de programas em execuo sem depender de qualquer definio de arquivo fora
do programa. possvel utilizar esses comandos para especificar realmente cada
aspecto de um arquivo do banco de dados, alm dos dados atuais do arquivo. As
mesmas capacidades que eles oferecem para a criao dos arquivos tambm podem
ser utilizadas para a modificao de arquivos existentes, inclusive para a adio e
excluso de campos, ndices e de segmentos de ndice. Finalmente, para complementar
as capacidades do grupo em especificar atributos dos arquivos e seus componentes,
existe uma capacidade paralela para consultar o estado existente dos mesmos atributos
dos arquivos existentes.
A maior parte do estruturao e reestruturao dos arquivos feita em um bloco iniciado
por um comando structure_start e finalizado por um comando structure_end. Nesse
bloco, os atributos so configurados pelo comando set_attribute e consultados pelo
comando get_attribute. Nenhum desses dois ltimos comandos est no grupo de
Estrutura, porque eles so utilizados para a configurao e consulta dos atributos em
geral, e no para apenas atributos dos arquivos e seus componentes.
As operaes estruturais podem ser abandonadas ou canceladas, atravs da utilizao
do comando structure_abort, que desfaz todas as operaes de um bloco de estrutura
se o comando for executado antes do structure_end. As operaes da estrutura podem
ser baseadas nos atributos da estrutura de um arquivo existente atravs da utilizao do
comando structure_copy. Os campos e ndices podem ser adicionados ou excludos
utilizando-se comandos individuais para excluso ou criao.

186
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Todos os comandos deste grupo que no sejam structure_..., create_... e delete_...
podem ser executados fora dos blocos da estrutura, e os que podem alterar os atributos
(file_size, make_file, set_relate) no devem ser executados dentro dos blocos.
Abrindo Arquivos que no foram Declarados na File List
Com a opo as do comando open, possvel abrir um arquivo do banco de dados que
no seja o identificado no filelist. Isso pode ser til onde um grupo dos arquivos do banco
de dados dividem uma estrutura de campo comum mas possuem nomes ou caminhos
de diretrio diferentes. Com o open ... as, os nomes e caminhos do diretrio dos
arquivos fsicos podem, de fato, at serem inseridos em tempo de execuo.
Este elemento opcional do open deve conter o nome fsico do arquivo que deve ser
aberto (sem extenses), mais o caminho do diretrio quando for necessrio, seguido
pela palavra as. Seguindo o as, o nome DataFlex de um arquivo atual (criado por uma
entrada no filelist) deve ser declarado.
O arquivo fsico deve possuir campos idnticos em termos de nome, tipo, e a ordem na
qual eles esto no arquivo, em relao ao arquivo do banco de dados que est no filelist.
O Driver DataFlex de Banco de Dados
O DataFlex no est limitado utilizao dos arquivos de dados do formato DataFlex. O
DataFlex pode utilizar arquivos em qualquer formato para o qual voc possua um driver
para o runtime do DataFlex. Estes so fornecidos separadamente do runtime e sistemas
de desenvolvimento do DataFlex (entre em contato com seu distribuidor de DataFlex). O
termo utilizao se refere a todas as funes que o DataFlex capaz, incluindo
criao, excluso, e edio de registros. O driver Dataflex, e alguns outros drivers,
tambm suportam criao, excluso e modificao das estruturas (campos, ndices) dos
arquivos do banco de dados a partir de programas do DataFlex.
Tudo neste captulo, est relacionado com o driver do banco de dados DataFlex.
Funcionalidades equivalentes de outros drivers so descritas na documentao
fornecida com os mesmos.
Funes
Existem vrias constantes simblicas para o driver DataFlex. Elas so descritas na
tabela abaixo. Estas podem ser utilizadas no comando call_driver para chamar as
funes que representam.
NOME SIGNIFICADO
FLEX_SET_MAX_SORT_BUFFER Configura a quantia mxima de

187
d
o

B
a
n
c
o

d
e

D
a
d
o
s

NOME SIGNIFICADO
memria que ser utilizada na
reordenao. O padro 8
Megabytes, ou todo o disponvel, se
houver menos.
FLEX_GET_MAX_SORT_BUFFER Informa a maior quantia de memria
que ser utilizada para a reordenao.
FLEX_SET_INDEX_OPT Configura se os dados do ndice
podem ser retornados para o
programa nas procuras de registros.
FLEX_GET_INDEX_OPT Diz se os dados do ndice podem ser
retornados para o programa em
procuras de registros
FLEX_REPAIR_FILE Repara um arquivo que estiver
danificado.
FLEX_GET_REPAIRS_NEEDED Faz uma inspeo do cabealho do
arquivo, reportando os erros
encontrados.
FLEX_GET_STRICT_TRANSACTIONS Retorna se a ausncia de TTS gerar
um erro quando arquivos
SERVER_ATOMIC forem abertos
FLEX_SET_STRICT_TRANSACTIONS Configura se a ausncia de TTS gera
erro quando arquivos
SERVER_ATOMIC forem abertos
Algumas observaes sobre as funes acima:
Quando se repara um arquivo, existem duas etapas: (1) o cabealho
reparado, se necessrio; e (2) o arquivo reordenado, o que repara
ndices danificados e um arquivo .VLD corrompido. Se voc quiser
pular a reordenao, existe um parmetro do comando call_driver
para faz-lo.
Essas constantes so retornadas atravs do
FLEX_GET_REPAIRS_NEEDED para relatar quais reparaes sero
necessrias:

FLEX_HEADER_OK
FLEX_BLOCK0_BAD
FLEX_HEADER_BAD
FLEX_HEADER_INTEGRITY_OFF
FLEX_HEADER_UNREADABLE

188
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Se o FLEX_GET_REPAIRS_NEEDED retornar
FLEX_HEADER_UNREADABLE, provavelmente o arquivo no pode
ser reparado; se retornar FLEX_HEADER_INTEGRITY_OFF, ele
definitivamente no pode.
Para manter um arquivo do banco de dados reparvel, voc deve
manter sua verificao de integridade do cabealho ligada (no
Database Builder). Isso mantm um arquivo .HDR para o arquivo do
banco de dados que examinado pela funo
FLEX_GET_REPAIRS_NEEDED e utilizado pela funo
FLEX_REPAIR_FILE.
Se voc tentar configurar FLEX_SET_MAX_SORT_BUFFER para um
valor menor que 32K, voc receber um erro. Observe que essa
funo utiliza Kilobytes (1K =1024 bytes).
Essas constantes so retornadas pelo FLEX_GET_INDEX_OPT para
reportar sob quais condies os programas devem utilizar os dados
contidos nos ndices, ao invs de preencher o buffer do registro para
acessar os dados do registro depois de uma procura:

FLEX_INDEX_OPT_ON
FLEX_INDEX_OPT_OFF
FLEX_INDEX_OPT_PERMISSIVE

ON a configurao padro, permitindo a utilizao dos dados do
ndice para todos os segmentos que no so case-insensitive. OFF
impede a utilizao dos dados do ndice; o buffer do registro sempre
carregado. PERMISSIVE permite a utilizao de todos os dados do
ndice, incluindo aqueles dos segmentos de ndice case-insensitive.
FLEX_SET_STRICT_TRANSACTIONS til para utilidades e outros
programas que no entram ou editam transaes, e podem ser
executado sem o NetWare shell. Se um arquivo cujo atributo
DF_FILE_TRANSACTION estiver configurado como
SERVER_ATOMIC for aberto atravs de uma aplicao que no
esteja sendo executada sob o NetWare shell, um erro ser retornado.
Atravs da configurao da funo DFFALSE o erro ser suprimido e
a abertura permitida, sem a modificao do atributo do arquivo.
Funes de Callback

189
d
o

B
a
n
c
o

d
e

D
a
d
o
s

Vrios comandos (como call_driver, copy_db, sort, structure_end, e copy_records)
utilizam uma funo de callback para reportar o status de volta para o quem chamou. O
objeto que recebe a get_callback deve definir uma funo cuja primeira linha possui a
seguinte aparncia:
function CallBack [for class] string Callback_msg integer
Callback_type ;
returns integer
Sua funo de callback deve retornar DFTRUE ou DFFALSE. Se retornar DFFALSE, a
operao ir continuar. Se retornar DFTRUE a operao ser cancelada. O parmetro
for class permite a definio da funo para herana atravs de cada instncia da
classe.
Na entrada para sua funo de callback, a Callback_msg uma string. Callback_type
indica o tipo da mensagem que a Callback_msg contm. Callback_type ser uma das
seguintes:
DF_MESSAGE_TEXT uma mensagem genrica que no se encaixa a nenhum desses
tipos.
DF_MESSAGE_HEADING_1
cabealho do nvel mais alto.
cabealho do segundo nvel.
cabealho do terceiro nvel.
cabealho do ltimo nvel.
cabealho do ltimo nvel.
DF_MESSAGE_WARNING
mensagem aviso.
DF_MESSAGE_PROGRESS_TITLE
ttulo dos valores de progressos seguintes.
DF_MESSAGE_PROGRESS_VALUE
um ou dois valores que indicam o quo
longe a operao atual progrediu.
Conhecendo o tipo da mensagem, uma aplicao pode manipular inteligentemente a
exibio da mensagem. Por exemplo: se o tipo da mensagem for
DF_MESSAGE_WARNING, esta poder ser exibida em uma caixa de texto chamada
Warning. Alm disso, a aplicao pode fornecer uma oportunidade para os usurios
cancelarem a operao se uma mensagem de aviso for recebida isso pode ser
perigoso. Se eles abortarem durante uma classificao ou reestruturamento, os ndices e
at os arquivos podem se corromper.
Todas as mensagens se aplicam ao ltimo nvel do cabealho da mensagem. Uma vez
que um cabealho identifica a operao atual que est sendo executada, isso d uma

190
d
o

B
a
n
c
o

d
e

D
a
d
o
s

idia do que est acontecendo para o usurio. Como um exemplo, voc pode receber a
seguinte seqncia de mensagens:
TEXTO DA MENSAGEM TIPO DA MENSAGEM
Sorting file 1 DF_MESSAGE_HEADING_1
Building index 1. DF_MESSAGE_HEADING_2
Sorting file 2. DF_MESSAGE_HEADING_1
Visto que sabemos os tipos das mensagens, elas podem ser apresentadas para os
usurios de uma forma que a ltima mensagem visvel do cabealho para cada nvel
seja separada.
Mensagens de progresso (DF_MESSAGE_PROGRESS_VALUE) enviam um ou dois
valores inteiros separados por uma vrgula. O primeiro (ou nico) inteiro representa o
nvel atual da execuo da operao. O segundo inteiro representa o valor do nvel total
da execuo da operao atual. Por exemplo: um DF_MESSAGE_PROGRESS_VALUE
de 20,100 pode significar que 20 dos 100 registro foram lidos ou que 20% da operao
est completa. O significado do DF_MESSAGE_PROGRESS_VALUE especificado na
mensagem DF_MESSAGE_PROGRESS_TITLE. A seguir est um exemplo de uma
seqncia que pode ser aceita:
TEXTO DA MENSAGEM TIPO DA MENSAGEM
Sorting file 1. DF_MESSAGE_HEADING_1
Percent Complete: DF_MESSAGE_PROGRESS_TITLE


191
A
r
q
u
i
v
o
s

Apndice A Nomes de Arquivos & Tipos de Extenso
Cada arquivo do banco de dados do DataFlex uma famlia de arquivos do sistema
operacional que funcionam entre si como se fossem uma nica coisa para os usurios
do DataFlex. O arquivo rootname (especificado pelo usurio nas rotinas do IDE ou do
Database Builder) comum para todos os membros de uma famlia de arquivos de
dados, enquanto vrias extenses denotam vrias funes padres para cada um
desses arquivos.
A seguir esto as extenses padres e os nomes de arquivo utilizados pelo DataFlex. O
"*" na coluna Tipo indica que o arquivo necessrio em tempo de execuo. O "@"
indica que o arquivo s necessrio na compilao. As letras MAISCULAS NORMAIS
denotam nomes e extenses explcitos, enquanto em ITLICO representam um objetivo
ou classificao do arquivo cujo nome ou extenso so definidos pelo usurio.
NOME DO ARQUIVO TIPO DESCRIO
rootname.DAT *Random Arquivo de dados do DataFlex. Contm
a definio e os dados do arquivo (um
por arquivo do banco de dados)
rootname.HDR *Random Arquivo de backup de integridade do
cabealho
rootname.VLD *Random Arquivo de dados comprimido
rootname.K## *Random Arquivo de ndice do DataFlex (um para
cada ndice)
rootname.FD @Sequential Informao da definio de arquivo para
o compilador
rootname.DEF Sequential Listagem da definio de arquivo
rootname.TAG Sequential Arquivo dos nomes de caracteres dos
campos
rootname.BAD Sequential Registros duplicados ou corrompidos
encontrados na reindexao
program.VD7 *Flex Programa executvel do Visual
DataFlex
program.SYM Sequential Tabela de smbolos para o arquivo .VD7
program.VW Sequential Cdigo fonte da view de entrada de
dados
program.SRC Sequential Cdigo fonte do programa

192
A
r
q
u
i
v
o
s

program.INC Sequential Arquivo de incluso de cdigo fonte com
objetivo geral
program.PKG Sequential Arquivo de pacote de cdigo fonte para
criao da classe
program.PRN Sequential Cdigo intermedirio liberado pelo
compilador
program.FLP Flex Segmento de programa pr-compilado
pelo Compilador
program.PKI Sequential Tabela de smbolos para o arquivo .FLP
program.ERR Sequential Arquivo de erro produzido pelo
compilador
FLEX.CFL @Random Arquivo de comando de macro
DFCOMP @Program Programa de compilao do DataFlex
*.RSC Sequential Arquivo fonte
DFSYM Program Programa para produzir o arquivo de
smbolo .SYM a partir do arquivo .VD7
DFHELP.VD7 Flex Programa de manuteno da Ajuda
DFRUN *Program Programa de runtime do DataFlex
######.DFR Encrypted Arquivo de controle da contagem de
usurios
FILELIST.CFG *Random Filename padro da lista de nmeros de
arquivos ativos
TERMLIST.CFG *Random Arquivo de serializao
COLLATE.CFG Sequential Definio da seqncia de comparao
FLEXERRS.VD7 Flex Programa de manuteno de erros do
DataFlex
APPS.* Random Banco de Dados das aplicaes no IDE
CODEMAST.* Random Banco de Dados dos cdigos para as
listas de cdigo da aplicao
CODETYPE.* Random Banco de Dados dos tipos de cdigos
para as lista de cdigo da aplicao
FORMS.* Random Banco de Dados de forms do IDE
FIELDS.* Random Banco de Dados de campos nos forms
do IDE

193
A
r
q
u
i
v
o
s

HELPCTX.* Random Banco de dados da Manuteno do
contexto da Ajuda
HELPGRP.* Random Banco de Dados da Manuteno dos
grupos da Ajuda
HELPLNK.* Random Banco de Dados da Manuteno da
referncia cruzada da Ajuda
HELPSBJ.* Random Banco de Dados da Manuteno do
assunto da Ajuda
Atributos do DataFlex
Cada um desses atributos est documentado em sua prpria seo na Referncia de
Comandos do Visual DataFlex. Eles so especficos para o driver do banco de dados do
DataFlex, como podem ser vistos na primeira parte de seus nomes.
Diferenas da API
Tirando as excees listadas aqui, esses atributos se comportam igualmente na API e
no runtime do DataFlex.
O valor padro do DF_STRICT_ATTRIBUTES DFTRUE no runtime,
e DFFALSE na API.
O valor padro do DF_REPORT_UNSUPPORTED_ATTRIBUTES
DFTRUE no runtime, e DFFALSE na API.
O atributo DF_RUNTIME_PROGRESS_FREQUENCY no est na
API, e s pode ser utilizado somente no runtime do DataFlex.

194
A
r
q
u
i
v
o
s

Apndice B Especificaes do Visual DataFlex
Caractersticas
Ambiente Integrado de Desenvolvimento Avanado (IDE), com muitas
classes construdas e componentes e subclasses completamente
personalizveis.
Novo Code Explorer tornando leve a navegao, edio, e depurao
da programao do cdigo. Agora, o Code Explorer pode abrir
qualquer arquivo. Saltar para o erro editando erros de compilao.
O lder da indstria de gerao de relatrios, Seagate Crystal Reports
for DataFlex est incluso.
Debugger em nvel de cdigo integrado para ajudar a localizar e fixar
problemas.
Os ltimos servers e connectivity kits para desenvolvimento
client/server incluindo licena para desenvolvimento de dois usurios e
licenas de teste para Pervasive.SQL e IBMs DB2 Universal
Database.
Assistentes melhorados e aumentados para construo de numerosos
componentes de programao, incluindo aplicaes, views, e
importao de controles aclives.
Um Database Builder melhorado para construo de arquivos da base
de dados e Dicionrios de Dados reutilizveis.
Database Explorer para visualizao e edio dos dados crus.
Um sistema de Help com uma interface no estilo explorer, novo
Database Guide, e help on-line atualizado.
Um linguagem de 4 gerao totalmente orientada a objetos (4GL).
Data Access ODBC Connectivity Kit para acessar bases de dados
compatveis com ODBC a partir do Visual DataFlex (Instalado
automaticamente com o Visual DataFlex).
Requisitos
Por favor, consulte o Guia de Instalao e Ambiente para verificar os requisitos de
memria, espao em disco, e verses de sistema operacional que se aplicam sua
verso do Visual DataFlex.

195
A
r
q
u
i
v
o
s

Plataformas
As plataformas suportadas so Windows 98, Windows NT 4 e Windows 2000. Por favor,
consulte o Guia de Instalao e Ambiente para mais detalhes.
Estrutura
DBMS relacional estendido com utilitrios e comandos da linguagem independente dos
dados.
Connectivity Kits
O Visual DataFlex acessa vrios formatos diferentes de base de dados atravs de
Connectivity Kits. Connectivity Kits esto disponveis para IBM DB2, Microsoft SQL,
Pervasive.SQL e conexes ODBC. Os Connectivity Kits da Data Access permitem
converter para e de, bem como acessar diretamente, vrios formatos diferentes de base
de dados sem recompilao das aplicaes. Com exceo do ODBC, todos os
Connectivity Kits so Drivers nativos do VDF, e permitem acessar direta e rapidamente a
base de dados.
Especificaes da Base de Dados (Todas as Bases de
Dados usadas com VDF)
TIPO DESCRIO
Nmero mximo de tabelas por
Filelist
4095
Nmero mximo de Filelists por
aplicao
Ilimitado
Registros em arquivos DataFlex & Especificaes dos
Arquivos
TIPO DESCRIO
Nmero mximo de campos por
arquivo
255
Nmero mximo de caracteres no
nome fsico do arquivo (root name)
40
Nmero mximo de caracteres em
um nome de tabela enderevel
8

196
A
r
q
u
i
v
o
s

TIPO DESCRIO
um nome de tabela enderevel
(DataFlex name)
Tamanho mximo do arquivo 4 Gigabytes

Note: Consulte o Guia de Instalao
e Ambiente para informaes
detalhadas.
Nmero mximo de registros por
arquivo
16.7 Milhes (16,700,000)
Tamanho mximo do registro 16 Kilobytes (16,384 Bytes)
Tipo dos dados no arquivo Compactados, acesso randmico em
tamanho-fixo
Formato de armazenamento de
nmeros
BCD comprimido com ponto fixo.
Ponto flutuante
Preciso numrica Ponto fixo: 8 posies depois do
ponto decimal.
Ponto flutuante: 16 dgitos
significativos.
Tipo DECIMAL adiciona suporte a
16.16.
Regio Numrica Fixo: 9,999,999,999,999,999.
9999999999999999
com tipo DECIMAL.
Flutuante: 1.0e306
Especificaes de ndices para a base DataFlex
TIPO DESCRIO
Nmero mximo de ndices por
arquivo
15
Nmero mximo de segmentos por
ndice
16
Comprimento mximo do ndice 256 Bytes

197
A
r
q
u
i
v
o
s

Especificaes de Campos para a base DataFlex
TIPO DESCRIO
Nmero mximo de caracteres para
o nome do campo
15
Tamanho mximo dos dados em um
campo
16 Kilobytes (16.384 Bytes)
Tamanho mximo de um campo
ASCII
255 caracteres
texto
Tamanho de um campo data 3 Bytes (Fixo)
numrico
99,999,999,999,999.99999999 to -
9,999,999,999,999.99999999 (14,8
posies)
binrio
Aplicao / Cdigo
Especificaes dos tipos de dados para Visual DataFlex so encontrados neste manual.
Especificaes de tipos avanados de tipos de dados avanados e tipos estruturados
tambm so encontrados neste manual.
Todas as especificaes abaixo so por aplicao. Cada aplicao Visual DataFlex
pode chamar outras aplicaes VDF e no-VDF e retorna ao mesmo ponto do cdigo
aps o uso do comando chain ou runprogram.

TIPO DESCRIO
Nmero mximo de linhas por
programa
128 milhes (128.000.000)
Comprimento mximo da linha do
Editor de cdigo
255 caracteres
Comprimento mximo compilvel
para expresses
4095 caracteres (uma expresso
excedendo 255 caracteres deve ser
quebrada em mltiplas linha de

198
A
r
q
u
i
v
o
s

TIPO DESCRIO
cdigo, separadas por ponto-e-
vrgula, o qual indica a continuao
da expresso.
Comprimento mximo de mensagem
de erro personalizada
2048 caracteres
Nmero mximo de arquivos que
podem ser abertos simultaneamente
para E/S
10 arquivos
Faixa Inteira 2,147,483,647
Caractersticas do arquivo de
Programa
Cdigo protegido, semi-compilado
Nmero mximo de objetos 32.768
Nmero mximo de mensagens de
objetos
3.072
Nmero mximo de classes 32.768
Tamanho mximo de programas
compilados sem smbolos.
2 Gigabytes (2.147.483.648 Bytes)
Nmero mximo de arquivos abertos
simultaneamente
Limitado apenas pela memria
Tipos de argumentos Strings Texto
Numrico com ponto fixo
Numrico com ponto flutuante
Data inteira (formato Juliano)
Arquivo de Programa Visual DataFlex
Quando uma aplicao Visual DataFlex 7 compilada, um arquivo com uma extenso
.vd7 criado (por exemplo, MyApplciation.vd7). Este o arquivo que o programa
executvel do Visual DataFlex (dfrun.exe) executa quando a aplicao executada.
Para executar uma aplicao Visual DataFlex, simplesmente execute um duplo-clique no
arquivo .vd7, e a entrada no Registro do Windows associa o arquivo com o programa
executvel correto.

199
A
r
q
u
i
v
o
s

Tamanho do Argumento
O Visual DataFlex tem um tamanho global de argumento, o qual controla o
tamanho mximo de variveis strings locais e o tamanho um campo texto da
base de dados que pode ser enderevel na aplicao. O tamanho padro de
argumento no Visual DataFlex 7 32000 bytes. Este maior que o tamanho
mximo de um registro da base de dados DataFlex, mas se voc estiver
utilizando bases de dados no-dataflex ou acessando arquivos seqenciais
em sua aplicao voc pode precisar incrementar o tamanho do Argumento. O
tamanho mximo possvel para argumentos 2.000.000 (2 milhes) bytes.
Por razes de performance, voc deve manter o tamanho do argumento como
o mais baixo possvel para a sua aplicao.
Voc pode usar o comando get_Argument_Size, para determinar o tamanho do
argumento atual e o comando set_Argument_Size para aumentar o tamanho do
argumento atual.
Exemplo
Procedure DoAdjustArgumentSize
integer iArgSize
get_Argument_Size to iArgSize
if (ArgSize<64000) ;
set_Argument_Size 64000
End_Procedure // DoAdjustArgumentSize

Este exemplo aumenta o tamanho do argumento para 64000 se ele menor que 64000.
Para mais informaes veja:
- Nomes de Arquivos & Tipos de Extenso e Estrutura lgica de um arquivo no Guia da
Base de Dados.
- Tipos de dados neste manual.
- Criando um Novo Arquivo de Dicionrio no Help do Database Builder.

Apostilaguiabasedados

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostilaguiabasedados

Загружено:

Авторское право:

Доступные форматы

GUIA DA BASE DE DADOS

Вам также может понравиться