Descrio Geral do LBS

Este documento descreve detalhes de arquitetura e funcionamento do LBS e suas ligaes com outros mdulos do LBW, tais como LIFILE.dll e LT.lib.

Arquitetura do LBS
Mdulos O LBS implementa a camada de software do LBW responsvel por todo o gerenciamento das sesses de usurios, UDBs e bases de dados. Tambm responsvel por parte do gerenciamento das Listas de Ocorrncias, processos de indexao, desindexao e consulta e acesso a arquivos. O tratamento pesado de ndices e listas de ocorrncias fica sob responsabilidade da biblioteca LightText (lt.lib), assim como o controle mais refinado de acesso a arquivos responsabilidade da biblioteca LiFile.dll. Vejamos o desenho da arquitetura.

Aplicaes LBW Stub Cliente (clstub = lbs.dll) Servidor (LbwServer.exe)

LBS Diversas bibliotecas

LiFile.dll

Lt.lib Ctree.lib

Arquivos

Figura 1.

Arquitetura geral do LBS

As aplicaes LBW utilizam o stub cliente do LBS (para verses cliente/servidor) ou o prprio LBS (para verses rede e monousurio). Para o LBS, o LbwServer uma aplicao qualquer, como se fosse um cliente. A seguir esto as principais classes e funcionalidades so implementadas pelo LBS:

Classe LBSC_Session

LBSC_Base

LBSC_Field

LBSC_Data C_Date C_Time LBSC_EntParser

LBSC_LicControl LBSC_Occurrence LBSC_OLSort

LBSC_OpInfo

Descrio Responsvel pelo tratamento de login/logout, abertura/fechamento/criao/reprocessamento de bases, gerncia de cadastro de usurios, gerenciamento de licenas, incorporao/desincorporao de bases, reservar bases para manuteno. Responsvel pelas operaes sobre uma base aberta, como navegao, indexao (total e parcial), desindexao, pesquisa, gerenciamento de OLs, tratamento de campos e repeties, navegao nos ndices, tratamento de stopwords, fonemas, batimento de listas, gerenciamento de contadores e tratamento de ACLs. Representa um campo de uma base aberta. No visvel para as aplicaes. O objeto LBSC_Record possui uma lista de objetos LBSC_Field, cada um representando um campo da base. responsvel pelo tratamento das gowords e gerencia as repeties. Representa uma repetio de um determinado objeto LBSC_Field, que possui uma lista de LBSC_Data, uma para cada repetio. Implementa tratamento de datas. Implementa tratamento de horas. Representa o parser para indexao/desindexao de campos com ENTIRETREE. derivada de LTC_PARSER, da Lt.lib. Implementa todo o controle de licenas, tanto em cpias monousuario quanto em rede quanto em cliente/servidor. Representa uma ocorrncia no nvel LBS. As ocorrncias do LT so traduzidas para o nvel LBS. Classe responsvel pela ordenao de listas de ocorrncias. Pode ordenar uma lista sobre ela mesma ou gerar outra como resultado da ordenao. Tambm ordena a lista fsica. Usa as classes SortObject e Comparator para fazer o trabalho pesado de ordenao. Usada apenas para gerar informaes de feedback para as aplicaes. Contm

Header File Sesscl.h

Basecl.h

Fieldcl.h

Datacl.h Datecl.h Timecl.h Entparcl.h

Licctrl.h Occurcl.h Olsort.h

Opinfocl.h

LBSC_Parser

LBSC_Record

C_TERGetToken

informaes sobre o estado atual de uma determinada operao. Essas informaes so preenchidas pela classe que est realizando a operao (normalmente LBSC_Session e LBSC_Base) e so requisitadas pela aplicao atravs de uma API especfica. Responsvel pelo trabalho de parsing durante o processo de indexao/desindexao de campos que sejam indexados por rvores diferentes de ENTIRETREE. derivada de LTC_PARSER, da Lt.lib. Representa o registro corrente em memria dentro de uma base aberta. Cada objeto LBSC_Base possui um objeto LBSC_Record, que representa o registro corrente. Responsvel pelo processo de parsing sobre campos TER. Tabela 1. Principais classes do LBS

Parsercl.h

Record.h

TE_Token.h

Formatos dos Arquivos O LBS utiliza uma srie de arquivos para compor uma base de dados. Esses arquivos guardam informaes de controle sobre os dados, as ACLs, a estrutura da base, status de indexao, stopwords, gowords e os prprios dados. Arquivo LB1 O arquivo LB1 contm um header que armazena informaes tcnicas sobre a base de dados e contm tambm um registro de tamanho fixo para cada registro existente na base. Ou seja, os dados dos registros no esto nesse arquivo. Os registros de tamanho fixo so teis para podermos fazer seek rapidamente sobre um registro qualquer e da obter o endereo dos dados de tal registro, que ficam no arquivo LB4. O header de LB1 contm a seguinte estrutura: Tipo int int int int Nome do campo iSlotNum iCountNum iMaxKeySize iIntPart Descrio Nmero de slots na base Nmero de contadores na base Tamanho mximo de uma chave no sistema de ndices da base Nmero de dgitos da parte inteira de um nmero no sistema de ndices da base

int long long long long long long unsigned long unsigned long UINT BOOL BOOL

iDecPart lDeletedRecNum lDeletedRecNumReorg lNumRecords lLastRecPos lFirstRecActivePos lLastRecActivePos ulCreateDate ulLastModifyDate uiLastFieldId bIsEncrypt bReExport

BOOL BOOL BYTE DWORD DWORD CL_StringN<FU LLNAMESIZE > CL_StringN<US ERNAMESIZE > CL_StringN<US ERNAMESIZE > CL_StringN<M AXBASEPASS > CL_StringN<M AXMAINTENA NCEPASS>

bBaseIndexed bOnLineIndex bBaseType dwBaseId dwUserBaseId szUserBase szOwnerName

Nmero de dgitos da parte decimal de um nmero no sistema de ndices da base Nmero de registros deletados na base Nmero de registros deletados para disparar um reprocessamento automtico da base Nmero total de registros na base Ponteiro para o ltimo registro em LB1 Ponteiro para o primeiro registro ativo em LB1 Ponteiro para o ltimo registro ativo em LB1 Data da criao da base Data da ltima modificao da base ltimo identificador de campo que foi utilizado Indica se a base criptografada ou no Indica se a base pode ser exportada ou no (isso no usado. Foi criado porque o LBS deveria tratar de exportao da estrutura da base, mas depois isso mudou e o LBW quem faz isso hoje) Indica se a base est totalmente indexada. Se for FALSE porque pelo menos uma informao no foi indexada. Indica se a indexao da base est On-Line ou no. Tipo da base (pblica, restrita, etc.) Nmero de identificao da base Identificador da UDB qual a base pertence Nome da UDB Nome do usurio dono da base

szLastModifyUserName Nome do usurio que fez a ltima alterao na base szBasePassword Senha da base

szMaintenancePassword Senha de manuteno da base

Tabela 2.

Header de LB1

A estrutura que representa o header de LB1 e pode ser encontrada no arquivo lbstypes.h.

Cada registro de LB1 contm a estrutura abaixo: Tipo unsigned long unsigned long CL_StringN<USER NAMESIZE> CL_StringN<USER NAMESIZE> BYTE Nome do campo Descrio ulCreateDate Data de criao do registro ulModifyDate Data da ltima alterao feita no registro szLastModifyUserName Nome do usurio que fez a ltima alterao no registro szOwnerName Nome do usurio que criou o registro bRecStatus Status atual do registro. Possveis valores so: REC_INDEXED, REC_EXCLUDED, REC_LOCKED, REC_UPDATED, REC_INLOGFILE. Esses valores esto definidos em lbsdefs.h. Contador de acessos ao registro Apontador para o incio do registro em LB4 Registro de LB1

unsigned long long

ulAccess lContentPos Tabela 3.

A estrutura que representa um registro em LB1 TControlRec e pode ser encontrada no arquivo lbstypes.h. A figura abaixo ilustra o arquivo LB1.

... TControlRecHea d Nmero Mgico Figura 2.

TControlRec

Formato do arquivo LB1

Esse arquivo implementado como um objeto da classe C_LB1, que implementado em Lifile.dll. Essa classe que trata o nmero mgico, citado na figura acima. Para maiores detalhes sobre essa classe consulte informaes sobre Lifile.dll, mais adiante. O header do LB1 sempre criptografado, mas os registros s o so se o usurio criar a base como sendo criptografada.

Arquivo LB3 O arquivo LB3 contm a estrutura da base. Nele esto contidas as informaes sobre todos os campos, slots e contadores. Assim como o LB1, esse arquivo tambm composto por um header e por registros de tamanho fixo. O header contm informaes gerais sobre os campos e slots e contm tambm os prprios contadores, que so informaes de tamanho fixo. Como a quantidade de contadores e de slots de uma base no pode mudar depois que ela criada, d para guardar essas informaes no header sem problemas. Observe que o header de um arquivo LB3 pode diferir em tamanho de base para base, dependendo de quantos contadores e de quantos slots a base possui. Cada registro no arquivo LB3 contm informaes sobre um campo da base. Os campos deletados permanecem nesse arquivo at um reprocessamento da base. A estrutura abaixo representa o header de um arquivo LB3. Tipo int SlotPointer Nome do campo iNumber OfFields spSlot[ 1 ] Tabela 4. Descrio Nmero de campos na base Vetor de slots e contadores

Header de LB3

A estrutura de dados que representa esse header TStructHeadRec, que pode ser encontrada no arquivo lbstypes.h. O atributo spSlot um array de, inicialmente, um nico elemento. Mas na criao e abertura de cada base o LBS refaz o tamanho desse array, baseado no nmero de slots mais o nmero de contadores. Cada contador ocupa um spSlot e s. Um slot, no entanto, possui tamanho varivel. Ento um spSlot que representa um slot possui o tamanho atual do slot e um apontador para uma rea no arquivo LB4, que contm os dados do slot. Abaixo temos a definio da estrutura que representa um registro de LB3. Tipo CL_StringN<FIELDNAMESIZE> CL_StringN<DESCRIPTIONSIZE> Nome do campo Descrio szFieldAliasName Nome do campo (alias) szFieldDescription Descrio do campo (nome longo) CL_StringN<FIELDPASSWORDSIZE> szFieldPassword Senha do campo BYTE bFieldType Tipo do campo: pode

UINT

uiFieldAttrib

long UINT TIndexAttrib

lFieldSize uiFieldId tiaIndexAttrib

long

lLinkListPointer

assumir um dos seguintes valores: VALUE_FIELD, DVALUE_FIELD, ALPHA_FIELD, TEXT_FIELD, BINARY_FIELD, DATE_FIELD, DATE_FIELD, REFERENCED_FIELD, BYTE_FIELD, SINT_FIELD, FLOAT_FIELD Mscara de bits para indicar vrios estados do campo. Possveis valores so: NULL_ATTRIB (nenhum atributo especial setado), DELETED_FIELD (campo deletado), ASC_ORD_FIELD (campo ordenado de forma ascendente), DESC_ORD_FIELD (campo ordenado de forma descendente) esses dois ltimos valores so exclusivos (no devem ser setados ao mesmo tempo) Tamanho do campo, em bytes Identificador do campo Mscara de bits indicando as rvores de ndices utilizadas pelo campo. Possveis valores so: WORDTREE, BACKTREE, VALUETREE, DATETREE, TIMETREE, SOUNDTREE, REFERENCETREE, UNIQUETREE, ENTIRETREE No utilizado. Deveria ser um ponteiro para uma estrutura de dados que ficaria em outro arquivo

SlotPointer

spSlot

qualquer para definir links com outras bases. Seria uma forma de implementar relacionamentos, mas foi abandonada. A estrutura ficou porque ficou... Estrutura de controle do slot do campo. Cada campo possui um e somente um slot. Essa estrutura contm o tamanho desse slot e um apontador para o arquivo LB4, que contm o slot propriamente dito.

Tabela 5.

Registro de LB3

A estrutura TStructRec representa um registro de LB3 e est definida no arquivo lbstypes.h. Os valores para bFieldType e uiFieldAttrib esto definidos em userdefs.h e para tiaIndexAttrib, em const.h (arquivo da biblioteca LT.lib). A seguir, o formato do arquivo LB3.

... TStructHeadRec Nmero Mgico Figura 3. Formato do arquivo LB3

TStructRec

Esse arquivo implementado como um objeto da classe C_LB3, que implementado em Lifile.dll. Essa classe que trata o nmero mgico, citado na figura acima. Para maiores detalhes sobre essa classe consulte informaes sobre Lifile.dll, mais adiante. Da mesma forma que em LB1, o header de LB3 sempre criptografado, mas os registros s o so se a base for assim criada. Sugesto: criptografar os registros de LB3 sempre. Arquivo LB4

Esse arquivo contm um header e um conjunto de registros de tamanho varivel e armazena os dados de cada registro (todas as repeties), e os slots de base e de campo. O header no tratado pelo LBS e sim por Lifile.dll, que quem implementa a classe C_LB4, responsvel por todo o gerenciamento dos registros de tamanho varivel. Cada registro de LB4 representa um registro de LB1, mas quebrado em vrias partes que representam os campos do registro e as repeties de cada campo. Na verdade, um registro de LB4 formado por vrios registros menores, com a seguinte formao: registro inicial contm o nmero de campos vlidos para o registro atual de LB1. Vamos chamar esse nmero de campos de iNrFields; para cada iNrFields, h um outro registro em LB4 contendo informaes fixas sobre cada campo. Entre essas informaes temos o nmero de repeties (chamemos de iNumberOfRepetition) e o apontador para a primeira repetio, que tambm est em LB4 (que vamos chamar de lFirstRepetition). Todos esses registros que representam os campos esto contguos, formando um array logo depois do registro principal (o que contm iNrFields); por fim, cada repetio representada por um outro registro, que contm o tamanho da repetio e a prpria, como uma tira de bytes. As repeties so gravadas como uma lista encadeada, onde cada n uma repetio do i-simo campo. O incio da lista lFirstRepetition.

Vejamos cada estrutura: Nome do campo CL_StringN<RECORDPASSWORDSIZE> szPassword Tipo Descrio Senha do registro. No usada hoje porque o esquema de bases com registros privados no utilizado. Representa o nmero de campos com informaes para o registro referenciado por LB1. No necessariamente igual ao nmero de campos da base, indicado em LB3. Voc pode ter um certo nmero de campos na base (LB3) e outro nmero, maior ou menor, aqui em LB4. Esse nmero aqui indica os campos que tm informaes gravadas para o registro.

int

iNrFields

Tabela 6.

Registro primrio de LB4

A estrutura acima representa um registro primrio em LB4 e definido pela estrutura TContentRecPsw, descrita em lbstypes.h. Abaixo temos outra estrutura, que representa cada campo do registro. Tipo UINT int long Nome do campo uiFieldId iNumberOfRepetition lFirstRepetition Tabela 7. Descrio Identificador do campo. o link entre um campo que est em LB4 e as informaes que esto em memria (que so carregadas de LB3). Nmero de repeties do campo corrente, em LB4. As repeties esto dispostas em uma lista encadeada no arquivo LB4. Ponteiro para o incio da lista de repeties.

Segundo registro de LB4

Cada um dos iNrFields-simos campos do registro representado por um registro com a estrutura acima, que definida como TContentRec e est descrita em lbstypes.h. Esses registros so dispostos em um vetor logo depois do registro TContentRecPsw. Isso facilita o acesso. Observe que lbstypes indica que essa estrutura do arquivo LB2, que no existe mais. que h algumas verses atrs uma base LBS possua um arquivo chamado LB2, que continha registros TContentRecPsw e TContentRec. O ponteiro lFirstRepetition apontava para uma posio dentro de LB4. Depois juntamos todos os registro no arquivo LB4 e matamos o LB2. Finalmente, cada iNumberOfRepetition-sima repetio est em uma lista encadeada, onde cada nodo representado pela estrutura abaixo. Tipo long long Nome do campo lRepetitionSize lNextRepetition Tabela 8. Descrio Tamanho da repetio, em bytes Apontador para a prxima repetio. Zero para final de lista. Terceiro registro de LB4

Logo depois de cada estrutura dessa temos uma tira de bytes que a repetio propriamente dita. Esse nodo de lista representado pela estrutura TrepetitionRec, que est descrita no arquivo lbstypes.h. Abaixo temos uma figura ilustrando o formato do arquivo LB4.

Header ... ...

TContentR ec TContentRecP sw Nmero mgico

Informao (repetio) TRepetitionRe c

Buraco livre

Figura 4.

Formato do arquivo LB4

Observe que h um header no arquivo, mas no gerenciado pelo LBS. A classe C_LB4 quem usa esse header, que controla a lista de buracos livres no arquivo. As informaes contidas nesse arquivo s so criptografadas se a base for criada como sendo criptografada. Arquivo LB5 O arquivo LB5 contm informaes sobre os registros que foram gravados enquanto a base estava com indexao off-line. Ele contm uma mscara de bits, onde o i-simo bit corresponde ao i-simo registro da base, em LB1. Um bit ligado indica que o registro correspondente no foi indexado. Quando a indexao da base est off-line cada registro que alterado ou adicionado na base vai para o arquivo LB5. Isto , o bit correspondente ao registro ligado em LB5. Quando esse registro indexado, seja por uma indexao total, parcial ou porque o usurio ligou a indexao (tornou on-line) e alterou o registro, o bit correspondente zerado. O arquivo contm grupos de bits, que representam grupos de registros. Um grupo de bits na verdade um inteiro, que representa 32 registros da base. Quando precisamos acessar um bit que no est no arquivo, novos grupos so adicionados at que o bit desejado esteja no arquivo. Existe uma classe que foi criada especialmente para cuidar dessas continhas de bits. Tratase da C_IDXOFF (definida nos arquivos idxoffcl.h e idxoffcl.cpp), que est implementada dentro do LBS. Esse classe possui API para tratar dos grupos de bits, ligar um bit

correspondente a um determinado registro, desligar um bit, etc. No tem mistrio. s sacar aritmtica de bits. Voc vai encontrar no arquivo lbstypes.h algumas estruturas que dizem ser referentes ao arquivo LB5. Esquea. Isso no faz mais sentido. que o arquivo LB5 seria dedicado a outros fins e depois decidimos fazer dele o arquivo de log de indexao off-line. O formato desse arquivo bastante simples, como ilustra a figura abaixo.

...

Blocos de bits Nmero mgico

Figura 5.

Formato do arquivo LB5

O arquivo LB5 nunca criptografado. Arquivo LB6 O arquivo LB6 uma cpia do header arquivo LB1. No h registros. Apenas uma cpia das informaes necessrias para tentar uma recuperao em caso de pane no arquivo LB1. Sempre que uma base fechada com segurana, o header de LB1 copiado para LB6. Na abertura da base, o LBS faz um batimento entre o LB1 e o LB6 para verificar se h alguma inconsistncia. O arquivo LB6 sempre criptografado.

Arquivo LB7 Esse arquivo contm todas as permisses (ACLs) definidas para a base. O formato desse arquivo mudou quando implementamos as ACLs de componentes no LBS. Ou seja, quando o nmero mgico das bases passou para COMPONENTPERM_MAGICNUMBER, o formato desse arquivo mudou. O cdigo no LBS consegue ler e gravar informaes no

arquivo LB7 independentemente do formato utilizado. O LBS verifica a verso da base para saber como tratar esse arquivo.

Formato 1 Quando o nmero mgico da base menor que COMPONENTPERM_MAGICNUMBER, o arquivo LB7 contm apenas as listas de permisses para base, campo e registro. No h nmero mgico nem header para esse arquivo. As listas de permisses so: lbscaBaseUserAcl lbscaBaseGroupAcl lbscaFieldUserAcl lbscaFieldGroupAcl lbscaRecordUserAcl lbscaRecordGroupAcl

Isso gera um furo de segurana, pois no h nenhuma informao que diga que um arquivo LB7 pertence a uma determinada base. Sendo assim, posso criar uma base com a mesma estrutura da sua e definir as ACLs do jeito que quiser e depois trocar os arquivos LB7. A eu tenho as permisses que eu quero, sendo que na sua base. Isso nunca foi tentado, mas acho que funciona. Ateno: isso segredo, hein! No divulgar isso, pois um furo. Cada lista gravada/lida da seguinte forma: iNumElem (int) nmero de elementos na lista de usurios/grupos LBSC_ACL (iNumElem vezes) cada um contm a seguinte informao: szName (USERNAMESIZE) nome do usurio/grupo lbscplPermList (LBSC_PermList) lista de permisses para o szName. Cada um contem: iNumElem (int) numero de elementos na lista de permisses LBSC_Perm (iNumElem vezes) cada um contm a seguinte informao: lId (long) id da base/registro/campo bPermission (BYTE) mscara de bits com as permisses

Todas as listas so gravadas no mesmo arquivo, uma aps a outra, na seqncia indicada acima. Formato 2

Quando o nmero mgico da base igual ou maior que COMPONENTPERM_MAGICNUMBER, o arquivo possui um nmero que identifica qual a base que dona do LB7 (lembra do dwBaseId, de LB1?), as listas de base, campo e registro, como no formato 1, e as listas de formulrios e relatrios, seguindo a ordem abaixo: dwBaseId da base que dona do LB7 lbscaBaseUserAcl lbscaBaseGroupAcl lbscaFieldUserAcl lbscaFieldGroupAcl lbscaRecordUserAcl lbscaRecordGroupAcl lbscaFormUserAcl lbscaFormGroupAcl lbscaReportUserAcl lbscaReportGroupAcl Cada lista gravada/lida da seguinte forma: iNumElem (int) nmero de elementos na lista de usurios/grupos LBSC_ACL (iNumElem vezes) cada um contm a seguinte informao: szName (USERNAMESIZE) nome do usurio/grupo lbscplPermList (LBSC_PermList) lista de permisses para o szName. Cada um contem: iNumElem (int) numero de elementos na lista de permisses LBSC_Perm (iNumElem vezes) cada um contm a seguinte informao: lId (long) id da base/registro/campo bPermission (BYTE) mscara de bits com as permisses szId (COMPONENTNAMESIZE) nome do componente

Todas as listas so gravadas no mesmo arquivo, uma aps a outra, na seqncia indicada acima. No incio do arquivo existe o identificador da base e depois disso vm as listas. Observe que a estrutura LBSC_Perm muda do formato 1 para o 2. que os identificadores de componentes so strings e no nmeros. Sendo assim, foi necessrio alterara a estrutura para que ela seja capaz de armazenar tanto uma informao de permisso de base, campo e registro como de um componente. Os arquivos LB7 com formato 2 so sempre criptografados, mas os de formato 1 no. Vejamos as estruturas do formato 1 e 2 graficamente.

Formato 1 Identificador da base lbscaBaseUserAcl lbscaBaseGroupAcl lbscaFieldUserAcl lbscaFieldGroupAcl lbscaRecordUserAcl lbscaRecordGroupAcl lbscaFormUserAcl lbscaFormGroupAcl lbscaReportUserAcl lbscaReportGroupAcl

Formato 2

Figura 6.

Estrutura do arquivo LB7

O identificador da base contido no incio do arquivo (no formato 2) garante que o usurio no consegue furar o sistema da forma que podia ser feito antes. Se eu criar outra base com o mesmo formato da sua, criar as minhas permisses e tentar substituir seu arquivo LB7 pelo da minha base no vai funcionar, pois cada base possui um identificador nico. Detalhes sobre isso podem ser encontrados mais adiante, quando falarmos sobre o funcionamento do LBS. Arquivos LTC, LTI e LTL No sei detalhes sobre esses arquivos. So da biblioteca LightText. Arquivo STD O arquivo STD contm apenas 256 bytes, sempre. Ele armazena uma tabela utilizada para a normalizao de strings dentro do LBS e do sistema de ndices. Essa tabela formada por 256 caracteres, um para cdigo ASCII existente. Cada posio da tabela deve conter o caracter que substituir outro de mesmo cdigo ASCII. Exemplo: suponha que na posio

de ndice 65 da minha tabela STD eu tenha a letra W. Isso significa que sempre que uma string for normalizada todas as letras A (que tem o cdigo 65) sero substitudas por W. Sempre que uma base criada, o LBS cria um STD com uma tabela de normalizao padro, que converte todos os caracteres para maisculos e retira todos os acentos e cedilhas. Arquivo Gowords.lb Esse arquivo define o MINKEYSIZE e contm definies das gowords de todos os campos da base. Seu formato bastante simples (como um .ini) e fcil de usar. Sempre que uma base criada o LBS cria um arquivo Gowords.lb, baseado nas informaes contidas no lbs.ini. Voc pode alterar os valores default para a criao de arquivos gowords.lb alterando o lbs.ini. Arquivo StopWord.lb uma seqncia de tokens, um por linha, determinando quais as palavras que no devem ser indexadas. Normalmente o criador de bases quem seta as stopwords para uma base, utilizando uma API do LBS, mas nada impede que o usurio altere o arquivo stopwrods.lb antes de o LBS abrir a base. Arquivo .NET Este arquivo utilizado apenas em cpias rede do LBS. Serve para implementar um esquema de lock para as bases. Como na cpia rede as bases so compartilhadas por vrias mquinas, que processam localmente, necessrio fazer controle de lock em arquivo. O arquivo .NET implementa uma fila de controle de acesso ao arquivo LB1 de uma base. Seu formato o seguinte: um nmero mgico, que hoje igual a CRYPTO_MAGICNUMBER um header, que um short int, indicando qual o ltimo nmero utilizado para entrar na fila registros short int, indicando ordem na fila. No existem nmeros repetidos.

Esse arquivo gerenciado pela classe C_LB1, que detecta o tipo de cpia utilizado (rede, c/s, mono) e decide como implementar o esquema de lock (mtodos LB1_LockHead e LB1_ReleaseHead).

Vejamos o formato desse arquivo, graficamente:

...

Nmero mgico Header (short int) Registros (short int)

Figura 7.

Estrutura do arquivo .NET

Arquivo LicFile.lb Este arquivo utilizado para controlar licenas de uso do LBW em cpias rede. Cada licena utilizada ou liberada controlada neste arquivo. Existe um nmero mgico, que sempre LICFILE_MAGICNUMBER (pelo menos at a verso 3.3.5 do LBW), um header, representado pela estrutura TlicInfoFixHead (definida em lbstypes.h), que contm informaes de controle e registros contendo as licenas, que so representados pela estrutura TlicInfoFix (tambm definida em lbstypes.h). O header contm as seguintes informaes: bSomeMonoLog; // algum est em modo monousurio? bCanUse; // algum pode usar? tTime; // data/hora de criao do arquivo lNumRec; // nmero de registros com nmero de srie existentes no arquivo

Cada registro contm o formato descrito abaixo: tLicSerial; // estrutura que representa o nmero de srie strSerialSvc // nmero de srie iNumUsedLic // nmero de licenas usadas tLicClient; // estrutura que representa uma mquina cliente strClient // nome da mquina cliente strUserName // nome do usurio da mquina cliente iCount // quantas vezes o par usurio/mquina fez login

Vejamos graficamente:

... Header Nmero mgico Registros (TlicInfoRecSerial + TlicInfoRecClient)

Figura 8. Arquivo InfoFile.lb

Estrutura do arquivo LicFile.lb

Arquivo que contm informaes sobre as bases abertas em cpia rede. Cada base aberta cadastrada neste arquivo para que o executivo consiga exibir informaes sobre quantos e quais so os usurios que esto usando determinada base. Possui um nmero mgico, que pelo menos at a verso 3.3.5 do LBW igual a CRYPTO_MAGICNUMBER, no possui header e possui registros que contm informaes sobre cada base aberta e qual o usurio que est utilizando. Cada registro representado pela estrutura TbaseNetInfo, que est definida em lbstypes.h. As informaes contidas em cada registro so: strBaseName strUserLogged bDeleted // nome da base // nome do usurio que est utilizando a base // flag que indica se o registro est deletado ou vlido

Vejamos graficamente:

...

Nmero mgico

Registro s

Figura 9.

Estrutura do arquivo InfoFile.lb

Arquivo LbsCntrl Este o famoso arquivo de controle do LBS. um cadastro de todas as bases e UDBs de um ambiente de bases. Este arquivo contm todos os nomes de UDBs e bases, com suas UDBs, tipos e nomes longos. Seu formato o seguinte: um nmero mgico, que CRYPTO_MAGICNUMBER (pelo menos at a verso 3.3.5 do LBW) no possui header registros representados pela estrutura TbasesFile, definida em lbstypes.h

Cada registro contm as seguintes informaes: szBaseName // nome curto da base ou da UDB szUserBaseName // nome da UDB (vlido apenas para bases; UDBs tm esse valor vazio) szBaseLongName // nome longo da base (essa informao na verdade tambm est em um determinado slot da base, mas como o LBS no enxerga (enxergava) slots, ento o nome longo tambm est no arquivo de controle) bBaseType // tipo da base. Valores possveis so: BASE_PRIVATE BASE_PUBLIC BASE_PUBLIC_REC_PRIVATE BASE_PRIVATE_REC_PRIVATE USER_BASE.

bRecDeleted

// indica se o registro est deletado.

Funcionamento do LBS
Sesses As principais funcionalidades da classe LBSC_Session so: responder questes como: WhatServers, WhatBases, etc. (veja a lista de mtodos em sesscl.h) criar bases e UDBs deletar bases login/logout reprocessamento de bases e UDBs gerenciamento de licenas incorporao/desincorporao de bases reserva de bases para manuteno deleo de reas de memrias que foram alocadas e passadas para a aplicao

Os mtodos WhatServers, WhatServersForUser, WhatBases, WhatBasesOnServer, WhatBasesForUser e WhatBasesForUserOnServer tm implementaes no LBS.dll e no lbwserver.exe. O stub servidor quem de fato faz o trabalho a que se prope cada mtodo. O LBS responde apenas por s mesmo, como se fosse em cpia mono.

Reprocessamento O reprocessamento de uma base reduzido a basicamente trs operaes: criar uma base com a mesma estrutura da original copiar todos os registros e estruturas da base original para a nova renomear a base nova original para um nome qualquer e a base nova para a original

Quando a base nova criada, os campos recebem identificadores sequenciais, o que pode ficar diferente da base original. Por exemplo, se a base original tiver algum campo deletado, ento existe um buraco na sequencia de identificadores. Na base nova no vai existir esse buraco. Ento, a rotina de reprocessamento ajusta os identificadores da base nova para que eles reflitam exatamente a estrutura da base original. Isso muito importante.

Essa rotina de reprocessamento no eficiente como deveria ser, pois no consegue recuperar dados corrompidos da base original. Na verdade, o reprocessamento apenas um enxugamento da base, para retirar registros deletados e limpar o arquivo LB4, que possui lista de blocos e normalmente fica fragmentado com o tempo. necessrio implementar algum mecanismo de recuperao de informaes corrompidas ou pelo menos conseguir reprocessar a base que est corrompida. Hoje, se houver um problema grave em um registro, que provoque o travamento do lbs ou um loop na leitura do mesmo ou outro problema qualquer, a rotina de reprocessamento no vai conseguir trabalhar. Essa mesma rotina de reprocessamento utilizada para zerar uma base. Apenas o pedao de cdigo que faz a cpia dos registros no executada. Ento a base gerada fica com a estrutura novinha, enxuta, mas sem nenhum registro.

Bases Abertura Os arquivos LB1, 3 e 4 so abertos mas quem determina o modo de abertura (exclusivo, read-only, etc.) o LB1. Se esses arquivos forem abertos com sucesso, ento o resto do processo segue. Para carregar as ACLs, o LBS verifica se o identificador contido em um arquivo LB7 o mesmo do arquivo LB1 e s carrega as ACLs se esses nmeros forem iguais. Se as ACLs no forem carregadas todos os usurio e grupos ficaro com permisses indefinidas. o mesmo efeito de deletar o LB7. Uma pequena modificao no mtodo LBSC_Base::Open (arquivo basecl.cpp) pode impedir de a base ser aberta se o arquivo LB7 estiver invlido. s checar o valor de retorno do mtodo LoadAllAcls e decidir se prossegue com a abertura da base ou no. Os arquivos LB1, 3 e 4 (e os arquivos de ndice) so mantidos abertos enquanto a base estiver aberta. Os outros arquivos so fechados. Existe uma lista de lista de ocorrncias, chamada pcOLList. Essa lista contm cada LO que for gerada, sendo que a primeira (nmero 0) a LO fsica. Na abertura da base uma LO vazia criada e inserida em pcOLList. No interessa o contedo dessa LO. s para marcar a LO zero como sendo a fsica. Indexao/Desindexao Os processos de indexao de uma base, ao contrrio de um reprocessamento, so feitos pela classe LBSC_Base. Existem trs tipo de indexao e um de desindexao no lbs:

indexao on-line, feita cada vez que um registro gravado indexao parcial, que serve para atualizar os ndices referentes aos registros que foram gravados enquanto a indexao da base estava off-line reindexao total, que destri os ndices existentes e os recria, do zero, indexando todos os registros da base. desindexao on-line, que acontece cada vez que um registro atualizado. Antes de gravar um registro, o lbs o desindexa; depois de grav-lo, o lbs o indexa, se a indexao on-line estiver ativa.

O mtodo UpdateIndex responsvel pela indexao parcial, enquanto que o IndexAll realiza a indexao total de uma base. A desindexao on-line feita pelo mtodo Unindex, que disparado pelos mtodos UpdateRecord e DeleteRecord. A indexao on-line feita pelo mtodo Index, que disparado pelo UpdateRecord. Lock Existem basicamente trs pontos de lock no LBS: lock do header de LB1 lock de um registro em LB1 lock de contadores

O lock no header de LB1 serve para bloquear operaes mais lentas sobre a base e que interferem na estrutura da base e/ou na integridade dos dados. Por exemplo, quando o LBS vai adicionar um registro, o header de LB1 travado, pois o nmero de registros da base vai ser alterado e isso uma informao do header. Procure por LB1_LockHead no LBS e voc vai encontrar os pontos onde o header do LB1 usado com exclusividade. O lock de um registro feito quando a aplicao requisita isso. Serve para garantir que nenhum outro cliente gravar informaes nesse registro. O DBSM usa esse recurso quando entra no modo de edio de um registro. Outros clientes podem ler esse registros, mas no podem edit-lo, pois uma edio implicaria em um lock e o LBS negaria esse lock porque outro processo j o tem. O LBS mata o lock quando a aplicao se posiciona sobre outro registro, ou quando o registro corrente deletado ou por time-out de lock. O DBSM faz um release do lock no registro quando o usurio sai do modo de edio. O lock de contadores semelhante ao de registros. Quando se quer alterar o valor de um contador no LBS, necessrio fazer um lock nele antes. Isso garante que nenhuma outra aplicao estar alterando o valor do contador enquanto quem requisitou o lock no liberar esse lock. Cada um desses locks implementado conforme o tipo de cpia do LBS (mono, rede ou c/s). Mas quem implementa o mecanismo de lock na verdade Lifile.dll. O LBS apenas chama uma API.

UDBs As UDBs so meramente cadastro de usurios de um ambiente de bases. Para o LBS, uma base comum, mas com excees em alguns pontos do cdigo. Por exemplo, no permitido que uma aplicao faa um OpenBase de uma UDB. A tabela abaixo ilustra a estrutura de uma UDB:
Nome do campo USERBASEUSERNAME USERBASEUSERPASSWORD USERBASEUSERTYPE USERBASEUSERDESCRIPTION USERBASEUSERADDRESS USERBASEUSERPHONE USERBASEGROUPLIST USERBASEUSERCREATEDATE USERBASEUSERUPDATEDATE USERBASEACCESSBASES USERBASEACCESSTYPES Descrio User name User password User type User description User address User phone User groups User creation date User update date Bases that user can access Type of the base Senha PF1 PF2 PF3 PF4 PF5 PF6 PF7 PF8 PF9 PF10 PF11 Tipo ALPHA ALPHA VALUE ALPHA ALPHA ALPHA ALPHA DATE DATE ALPHA VALUE Tamanho USERNAMESIZE PASSWORDSIZE DESCRIPTIONSIZE ADDRESSSIZE PHONESIZE GROUPNAMESIZE FULLNAMESIZE nd WUE W W W W D D W V

Tabela 9.

Estrutura de uma UDB

Legenda para os ndices: W = WORDTREE U = UNIQUETREE E = ENTIRETREE D = DATETREE V = VALUETREE Observe que cada registro representa um usurio do sistema. Os campos USERBASEACCESSBASES e USERBASEACCESSTYPES so multivalorados e representam os nomes/tipos das bases onde o usurio tem algum tipo de acesso. Esses campos so teis para responder perguntas como WhatBasesForUser.

Cada UDB possui 5 slots e 5 contadores, que hoje no so utilizados. So reservados para algum uso futuro. Campos

Os campos so representados pela classe LBSC_Field. A tabela abaixo apresenta os possveis tipos de campo, com algumas caractersticas importantes.

Tipo Tamanho fixo VALUE_FIELD S DVALUE_FIELD S ALPHA_FIELD S TEXT_FIELD N BINARY_FIELD N DATE_FIELD S TIME_FIELD S REFERENCED_FIELD N BYTE_FIELD S SINT_FIELD S FLOAT_FIELD S Tabela 10. Tipos de campo

Requer tamanho N N S N N N N N N N N

Apenas o campo do tipo ALPHA_FIELD requer que a aplicao especifique seu tamanho no momento da criao da base. Esse campo tem tamanho fixo definido pelo usurio. Os campos REFERENCED_FIELD e BINARY_FIELD possuem uma parte com tamanho fixo, no incio de suas estruturas e depois uma tira de bytes representando o contedo do campo. Repeties As repeties representam cada valor de um campo multivalorado. Para o LBS, todos os campos so multivalorados. Quando o campo no est vazio ele possui pelo menos uma repetio. A classe LBSC_Data quem representa uma repetio. Segurana O LBS implementa pelo menos trs esquemas de segurana para as bases de dados: tipo da base senhas de base

 ACLs Alm disso, existe um outro esquema de segurana, que no est ligado a nenhuma base, que o Login.

Login A grande maioria dos mtodos da API do LBS requer que o usurio realize um Login antes. O Login a operao que abre as portas do LBS para que o usurio possa chamar outros mtodos com segurana. Esse mtodo serve para identificar junto ao LBS quem que vai usar o sistema e quais suas permisses. Assim, possvel determinar se o usurio que fez o Login pode ou no realizar determinadas operaes. Tipos de base Um esquema de proteo de uma base o seu tipo. Uma base pode ser: Pblica Restrita Pblica com restrio de registros (PRR) Restrita com restrio de registros (RRR)

Uma base pblica aquela onde todos os usurios podem mexer. Qualquer usurio pode alterar seus dados e sua estrutura. Uma base restrita uma base com segurana. Apenas alguns usurios podem alterar seus dados e estrutura. Esses usurios so: quem souber a senha da base quem estiver cadastrado nas ACLs da base se o cara for o dono da base Quando uma base PRR, seus dados so pblicos, sua estrutura pblica, mas os registros tm dono e cada um deles s pode ser visto pelos usurios que tm permisses. Essas permisses seguem a mesma regra acima (senha do registro, ACLs e o dono do registro). E finalmente para as bases RRR temos que a base restrita, com acesso somente para os usurios que atendam s exigncias citadas acima e ainda por cima disso cada registro possui seu esquema de permisso prprio, conforme as bases PRR. As bases PRR e RRR nunca foram usadas pelo LBW e, por isso, nunca foram testadas. Na verdade, quando o LBS foi implementado esse tipo de base foi testado. Mas depois o

cdigo foi sofrendo alteraes e isso nunca mais foi testado. Portanto, se um dia algum for colocar isso para funcionar no LBW, bom fazer muitos testes. Senhas Uma base LBS pode possuir duas senhas: uma para acesso aos dados e outra para acessar a estrutura, que chamamos de senha de manuteno. Para as bases pblicas essas senhas no fazem sentido. A senha de acesso aos dados serve para que o usurio passe por cima das permisses de ACLs quando for manipular os registros da base. Se a senha for informada corretamente, as ACLs no so nem verificadas e o usurio fica com permisso de administrador. A senha de manuteno serve para quando o usurio quer realizar algumas operaes de gerncia na base, como adicionar campos e alterar ACLs. O criador de bases seta as senhas de acesso aos dados e de manuteno com o mesmo valor quando a base criada. O dbam, por sua vez, vai tentando as senhas que tem no contexto para abrir a base. S quando nenhuma das senhas d certo que ele pede ao usurio para informar a senha da base. ACLs O LBS implementa hoje dez listas para controle de permisses. Cada lista dessas contm as permisses de cada usurio e/ou grupo para a base. Vejamos as listas que o LBS define: lbscaBaseUserAcl lbscaBaseGroupAcl lbscaFieldUserAcl lbscaFieldGroupAcl lbscaRecordUserAcl lbscaRecordGroupAcl lbscaFormUserAcl lbscaFormGroupAcl lbscaReportUserAcl lbscaReportGroupAcl

Elas representam, respectivamente, as seguintes ACLs: ACLs de BASE para usurios ACLs de BASE para grupos ACLs de CAMPO para usurios ACLs de CAMPO para grupos

ACLs de REGISTRO para usurios ACLs de REGISTRO para grupos ACLs de FORMULRIO para usurios ACLs de FORMULRIO para grupos ACLs de RELATRIO para usurios ACLs de RELATRIO para grupos

Existem duas situaes onde o LBS utiliza as ACLs: uma delas quando o prprio LBS precisa avaliar as permisses de um usurio para realizar alguma tarefa (VerifyPermission); a outra quando a aplicao pede ao LBS para verificar as permisses de um usurio (GetAclPerm). No caso do VerifyPermission o LBS verifica as permisses na seguinte ordem: USERFIELD, USERRECORD USERBASE GROUPFIELD/GROUPRECORD GROUPBASE

Observe que o VerifyPermission no utiliza as permisses de componentes (formulrios e relatrios). Ou seja, sempre que uma operao requer anlise de segurana, o LBS d prioridade s listas USERFIELD/USERRECORD (para campo ou registro, respectivamente); se a permisso desejada for encontrada, ou for explicitamente negada (ACL_NONE), ento o LBS j se d por satisfeito quanto analise das ACLs; se nada for declarado at esse ponto, o LBS verifica as permisses de base para o usurio correntemente logado (USERBASE); mais uma vez, o LBS pode encontrar a permisso desejada, ou uma negativa explcita (ACL_NONE); se ainda assim nada for encontrado, o LBS verifica a lista GROUPFIELD/GROUPRECORD; o ltimo caso procurar nas ACLs de BASE para todos os grupos do usurio que est logado. Se at esse ponto nada for declarado, o LBS retorna como ACL indefinida. Essas prioridades servem para que o LBS cheque sempre a permisso de maior validade para a tarefa. Por exemplo, suponha que MARIA possui permisso de ADM nas ACLs de BASE, mas as ACLs de um determinado campo indicam que MARIA s pode fazer READ. Ento, o LBS vai assumir a ACL de campo, que possui maior prioridade do que a de base. Com isso, mesmo definindo-se que MARIA possui acesso total a uma base, ainda assim possvel vetar explicitamente algum campo ou registro. Lembre-se que todo esse esquema de ACLs no vale para bases publicas. Para o GetAclPerm o esquema um pouco diferente: a aplicao quem pede para verificar uma determinada ACL. Se a aplicao pedir uma ACL de usurio o LBS verifica essa ACL e depois verifica a correspondente, nas ACLs de grupo.

A ordem para verificao de ACLs no GetAclPerm a seguinte: USERBASE/ USERFIELD/ USERFORM/ USERREPORT GROUPBASE/ GROUPFIELD/GROUPFORM/ GROUPREPORT

As ACLs de componentes (formulrios e relatrios) no so tratadas no VerifyPermission e so tratadas de forma semelhante no GetAclPerm: primeiramente so checadas as permisses de usurio e depois as do grupo: A tabela abaixo apresenta as ACLs existentes. ACL ACL_NONE ACL_READ ACL_WRITE ACL_APPEND ACL_DEL ACL_ADM ACL_RD_WR ACL_WR_APP ACL_RW_APP Significado Sem permisso Leitura de registros/repeties Gravao de registros/repeties Adio de registros/repeties Deletar registros/repeties (ACL_READ | ACL_WRITE | ACL_APPEND | ACL_DEL) (ACL_READ | ACL_WRITE) (ACL_WRITE | ACL_APPEND) (ACL_READ | ACL_WRITE | ACL_APPEND) Tabela 11. ACLs disponveis no LBS

Listas de Ocorrncias Cada pesquisa feita no LBS resulta em uma lista de listas de ocorrncias. Essas listas de ocorrncias so copiadas para a lista geral de OLs do LBS (pcOLList), que possui o primeiro elemento igual lista fsica. O ndice da OL dentro de pcOLList o handle da OL. Regies Crticas Antes de entrar em uma regio crtica importante analisar o fluxo de execuo do mtodo para evitar que no meio do caminho haja uma regio crtica de nmero menor do que a anterior. Isto , para entrar em uma regio crtica necessrio entrar na regio anterior, a no ser que voc tenha certeza que no vai haver uma inverso. Se houver inverso h o risco de dead-lock.

As regies crticas utilizadas pelo lbs esto descritas abaixo:

Regies Crticas para a Classe Base

RC1 --Atributo Mtodos onde aparece -------------------------------------------OwnerSession Create, Open, Close, UpdateStatus BaseUserAcl Create, Open, Close BaseGroupAcl Create, Open, Close FieldUserAcl Create, Open, Close FieldGroupAcl Create, Open, Close RecordUserAcl Create, Open, Close RecordGroupAcl Create, Open, Close UserData Close StopWordList Close, SetStopWord BaseName Open, Close (funo fnsplit) BasePath Open, Close (funo fnsplit) IsExclusive Open IsReadyOnly Open Struct Open OLList Open, ~LBSC_Base RC2 --Atributo Mtodos onde aparece -------------------------------------------CreateDate UpdateControlHeadStruct, UpdateBaseHead, ExportLB1Create LastModifyDate UpdateControlHeadStruct, UpdateBaseHead, ExportLB1Create LockTimeSleep UpdateControlHeadStruct, UpdateBaseHead, Open LockTimeOut UpdateControlHeadStruct, UpdateBaseHead, Open, SetLockTimeOut RC3 --Atributo Mtodos onde aparece -----------------------------------LB1 uma porrada. mostrar na tabela LB2 LB3 LB4 HeaderLocked Init, LockLB1Header bFastRec UpdateRecord, AppendRecord, EnableFastRecord

RC4 --Atributo Mtodos onde aparece -----------------------------------MaskList Init, ~LBSC_Base Phone Init, ~LBSC_Base Synonym Init, ~LBSC_Base BaseObjOk Init, ~LBSC_Base, GenerateNewStructFile, Create SelfDelete Init, Delete FullAccess Delete, Open RC5 --Atributo Mtodos onde aparece -------------------------------------------NavigationState Init, SetNavigationByIndex, Locate SearchType Init, SetNavigationByIndex, Locate NavigationIndex Init, SetNavigationByIndex szStdArray Init, SetNavigationByIndex RC6 --Atributo Mtodos onde aparece -------------------------------------------pOcListOfCurrKey SetNavigationByKey, Locate, Close NavigationKey SetNavigationByKey, Locate, Close NavigationField SetNavigationByKey, Locate, SetNavigationByIndex pcOLList SortOcList, Locate, SaveOcList, LoadOcList, UnloadOcList, DeleteOcList, GetNumOLRecords RC7 --Atributo Mtodos onde aparece -------------------------------------------Parser ChangeIndex EntParser ChangeIndex IndexSystem ChangeIndex, Create, Close RC8 --Atributo Mtodos onde aparece -------------------------------------------IndexTree IndexLT, IndexLTGoWord TimeId ResetLockElapsedTime, KillLockTimer LockPos LockRecord

RC9 --Atributo Mtodos onde aparece -------------------------------------------BaseUpdated ver listas CurrRecord RC10 ---Atributo Mtodos onde aparece -------------------------------------------OcAux Get*Record UserDataSize Init PrivateCreation Init SelfReorganize Init, SetReorganizeRecQuant bAppendingRec AppendRecord, UpdateRecord RC11 ---Atributo Mtodos onde aparece -------------------------------------------contadores PutCount, GetCount, IncCount DecCount, GetNextCount, GetPreviousCount RC12 ---------> regiao critica para proteger a operacao de criacao de registro. Nao trabalha sobre um membro especifico da classe.

Atributo Mtodos onde aparece -------------------------------------------AppendRecord RC13 ---------> regiao critica para proteger as operacoes de atualizacao, leitura e delecao de registro e a operacao de log. Nao trabalha sobre um membro especifico da classe.

Atributo Mtodos onde aparece -------------------------------------------UpdateRecord, ReadRecord, DeleteRecord, PrintLogUse

Regies Crticas para a Classe Session

CRITSECT0 --------Atributo Mtodos onde aparece -------------------------------------------lbscblBaseList ExportBaseFormat, OpenBase, CloseBase, DeleteBase, ReorganizeBase CRITSECT1 --------Atributo Mtodos onde aparece -------------------------------------------plbscuUser ~LBSC_Session, Init, Login, Logout plbsctTicket ~LBSC_Session, Init, Login, Logout CRITSECT2 --------Atributo Mtodos onde aparece -------------------------------------------bSLogin Init, SLogin bIsLogged Init, Login, Logout bIsMono Init, Login, Logout CRITSECT3 --------Atributo Mtodos onde aparece -------------------------------------------_clSessList LBSC_Session, ~LBSC_Session, Login GetFirstSession, GetNextSession, GetPreviousSession, GetLastSession _clLoginList Login, Logout _clLicList Login, Logout pLoginInfo Init, Login, Logout tLicFileCreateTime Login, Logout, Init, LicTimerProc _uLicTimerId LBSC_Session, ~LBSC_Session iNumLic Login, Logout _szLogFileName _iMaxLogUseFileSize _pclMaintBaseList SetBaseForMaintenance, OpenBase, GetReservedMaintBases

CRITSECT4 -> regiao critica para proteger um arquivo. Nao trabalha sobre um --------membro especifico da classe. Atributo Mtodos onde aparece -------------------------------------------cfBasesFile (arquivo de controle) CRITSECT5 -> regiao critica para proteger a operacao de criacao --------de base. Nao trabalha sobre um membro especifico da classe. Atributo Mtodos onde aparece -------------------------------------------CreateBase CRITSECT6 -> regiao critica para proteger a operacao de abertura --------de base. Nao trabalha sobre um membro especifico da classe. Atributo Mtodos onde aparece -------------------------------------------OpenBase

Regies Crticas para a Classe Field RC1 --Atributo Mtodos onde aparece -------------------------------------------Base Operator = FieldOrigName Operator = FieldType Operator = Error Operator = RC2 --Atributo Mtodos onde aparece -------------------------------------------AliasName Operator =, ModifyAliasName FieldDescription Operator =, ModifyDescription FieldId Operator =, SetId, Init Password Operator =, ModifyPassword, GetPassword FieldSize Operator =, ModifySize, Init IndexAttrib Operator =, SetAttrib, Init FlagStructUpdate Operator =, ModifyPassword, ModifyAliasName, ModifyDescription, ModifySize, Init RC3 --Atributo Mtodos onde aparece -------------------------------------------FlagUpdate Init, Clear, AddRepetition, ModifyRepByIndex. DelRepByIndex, Operator <<, operator = GoWord AddGoWord, DelGoWord, ~LBSC_Field DataList Clear, AddRepetition RepetFilePos Init lbscdlDataListClear, GetNumberOfRepetition, GetRepetitionByIndex, GetConstRepByIndex, GetRepetitionByVal, AddRepetition, ModifyRepetitionByIndex, DeleteRepetitionByIndex, operator [], operator =, operator <<, ClearAllDataSlots

Regies Crticas para a Classe Data

RC1 --Atributo Mtodos onde aparece -------------------------------------------OwnerField embutida nas macros SETFIELDUPDATE e DUPUNIQUEKEY, LBSC_Data, IsPermOk, SetError pbSlot SetSlot iSlotSize SetSlot RC2 --Atributo Mtodos onde aparece -------------------------------------------DataSize ModifyData, operator = Data ~LBSC_Data, ModifyData, operator =