Session - explanacao

TSESSION

Quando o Delphi acessa uma base qualquer ele cria automaticamente um componente do tipo TSession

com o nome Session. mesmo que voce nunca tenha ouvido falar nele. ele sempre esteve presente nas

suas aplicacoes.

Atravez do componente TSession o Delphi controle um conjunto de conexoes a uma base de dados.

normalmente apenas um componente TSession e' o suficiente para uma aplicacao. mas existem casos em

que uma aplicacao necessita de caracteristicas especiais para o controle do acesso.

Nestes casos um desenolvedor pode utilizar quantos componentes TSession julgar necessarios. cada

componente TSession seria utilizado para o controle de acesso a uma base. nao necessariamente do

mesmo tipo. podemos acessar indistintamente uma base Paradox. Oracle. Dbase. Interbase. etc ...

O componente TSession disponibiliza diversas propriedades para controle da conexao. sao elas :

PrivateDir

Atravez da propriedade PrivateDir estabelecemos onde serao criadas as tabelas temporarias criadas

pelo BDE quando necessario. Normalmente esta e' uma propriedade que deveria ser definida em tempo

de execucao. procedendo desta forma o desenolvedor pode definir um diretorio local na maquina do

usuario. existe um ganho de performance muito grande com este procedimento. como todas as tabelas

temporarias sendo criadas localmente o tempo de acesso e' extremamente reduzido facilitando todo o

trabalho da sua aplicacao.

Contudo a propriedade PrivateDir pode ser definida em tempo de desenvolvimento. uma vez que e' uma

propriedade published de TSession.

No caso de nao definir o PrivateDir manualmente sera considerado o PrivateDir definido no momento

da inicializacao do BDE.

No caso de uma aplicacao ter o seu executavel compartilhado em uma rede o diretorio atual da

aplicacao sera considerado o PrivateDir desta aplicacao.

Se diversos componentes TSession forem utilizados cada um devera ter o seu PrivateDir especificado.

NetFileDir

Assim como PrivateDir a propriedade NetFileDir pode ser definida em tempo de desenvolvimento. por

ser published. ou em tempo de execucao.

NetFileDir define onde sera acessado o arquivo de controle PDOXUSRS.NET, tambem conhecido como "Net

File". este arquivo e' necessario para o controle de compartilhamento de todos os usuarios.

Alguns cuidados sao necessarios para a correta utilizacao e configuracao desta propriedade de

TSession. no caso de uma definicao em tempo de execucao e' importante que este diretorio esteja

devidamente compartilhado na rede e que todos os usuarios tenham direitos para manipular e alterar

o arquivo.

Como este parametro e' relativamente estatico podemos defini-lo tranquilamente em tempo de

desenvolvimento ou em tempo de execucao.

Existem dois pontos importantes que devem ser observados quanto a utilizacao do NetFileDir.

1 - Nao podemos alterar o valor de NetFileDir quando existir alguma tabela aberta.

2 - NetFileDir e PrivateDir nao podem apontar para o mesmo diretorio

3 - Se uma tabela for aberta por um usuario. esta tabela so podera ser aberta por outro usuario que

apontar para o mesmo NetFileDir caso contrario uma execption sera gerado "This File is Controled By

Another Net File".

Keepconnections

A propriedade KeepConections e' do tipo Boolean e define como um componente TDatabase devera devera

administrar uma conexao quando nenhum Dataser estiver aberto.

Com KeepConections definido como True. um componente TDatabase devera manter a conexao com a base

de dados mesmo que nenhum dataset estiveja ativo no momento.

Com KeepConections definido como False. sempre que todos os datasets forem fechado a conexao e'

encerrada automaticamente.

O default para a propriedade KeepConections e' true. assim sendo a conexao com a base de dados so'

precisa ser feita uma unica vez. assim mesmo que sua aplicacao venha a fechar todos os datasets

abertos a conexao com a base sera mantida.

Este default existe apenas para facilitar o trabalho de controle da aplicacao que normalmente e'

atribuido ao desenvolvedor. na verdade o fato de ser mantida uma conexao sem que nenhum dataset

esteja realmente sendo utizado consome recursos do equipamento.

Quando o pessoal da Borland/Inprise deixou o KeepConections como true indiretamente eles estao

assumindo que o montante de recursos que sao alocados pela sua aplicacao em virtude da conexao nao

ser encerrada nao representa uma quantidade significando. assim optou-se por colocar a facilidade

de nao ter de controlar quando a conexao esta no ar ou nao

privilegiando o desenvolvedor.

SQLHourGlass

SQLHourGlas e'  uma propriedade do tipo Boolean que define se o cursor sera alterado para a

ampulheta durante as operacoes do BDE. Assim se SQLHourGlass estiver definido como true a ampulheta

sera utilizada como cursor do mouse sempre que o BDE estiver executando operacoes para a base de

dados. caso SQLHourGlass esteja como false o cursor nao sera alterado.

ConfigMode

ConfigMode define como a configuracao de Aliases dentro do BDE sera utilizada para a sessao atual.

ConfigMode nao esta disponivel em tempo de desen volvimento assim sendo nao devera estar disponivel

dentro o ObjectInspector.

A propriedade ConfigMode so deve afetar os aliases criados com os metodos AddAlias ou

AddStandardAlias.

Os valores possiveis para ConfigMode:

cfmVirtual - Todos os aliases criados dentro do BDE e os aliases criados locais a sessao estao

disponiveis

cfmPersistent - Os aliases definitivamente gravados dentro do BDE e os aliases criados localmente a

sessao mas adicionados ao armazenamento permanente estao disponiveis.

cfmSession - Apenas os Aliases criados localmente a sessao estao disponiveis para a sessao.

ConfigMode normalmente nao e alterado. o motivo principal talvez seja o proprio desconhecimento do

que a propriedade pode fazer. o valor default para ConfigMode e cfmVirtual. assim sendo todos os

aliases cadastrados no BDE. os aliases permanentes criados em tempo de execucao e os aliases nao

permanentes estao disponiveis a aplicacao.

Como existem diversas formas diferentes da sua aplicacao interagir com o BDE e todos os controles

disponiveis devemos utilizar a propriedades Config Mode com um certo criterio. Diversos

desenvolvedores optam por armazenar a configuracao de acesso a base de dados de seu aplicativo

dentro de uma base de dados do proprio sistema. assim toda a configuracao e estabelecida pelo

proprio aplicativo quando da inicializacao.

Observando por este aspecto a configuracao ideal seria cfmSession. assim a aplicacao teria o total

controle dos aliases. inclusive independente se existirem outros aliases ja definidos.

TraceFlags

TraceFlags e uma propriedade do tipo Set ( Conjunto ) com um ou mais valores possiveis que

especificam quais operacoes de banco de dados o SQL Monitor devera analisar para o componente

TSession.

Normalmente TraceFlags com o SQL Monitor sao utilizados durante a fase de otimizacao das Querys do

aplicativo. certamente nao sao todos os desenvolvedores que fazem esse tipo de trabalho mas e'

extremamente importante em aplicativos Cliente Servidor.

Os valores possiveis para TraceFlags sao :

tfQPrepare - As instrucoes de Prepare serao monitoradas

tfQExecute - As instrucoes de ExecSQL serao monitoradas

tfError - As mensagens de Erro do servidor serao monitoradas. o servidor podera enviar codigos de

erro dentro destas mensagens

tfStmt - Todas as instrucoes SQL serao monioradas

tfConnect - As operacoes de conexao e desconexao com a base de dados serao monitoradas. inclusive

alocacao e liberacao dos handles necessarios para cada conexao.

tfTransact - As instrucoes referentes as transacoes serao monitoradas. sao elas StartTransaction.

Commit e Rollback

tfBlob - As operacoes que envolvam tipos de campo blob serao monitoradas

tfMisc - Monitora qualquer operacao que nao estejam cobertas pelas outras opcoes de TraceFlags

tfVendor - As chamadas diretas a API do banco de dados serao monitoradas

tfDataIn - Os dados recebidos do servidor serao monitorados

tfDataOut - Os dados enviados ao servidor serao monitorados

Normalmente utilizamos estes valores para analisar um SQL que por ventura esteja demasiadamente

lento. afim de otimizar processos ou a modelagem da base de dados.

Evento OnStartUp

O evento OnStartUp e' especialmente interessante para estabelecer a configuracao inicial do nosso

componente TSession e de propriedades estrategicas de outros componentes de base de dados. isto

ocorre porque o Evento OnStartUp e' disparado antes de um OnLogin do TDatabase por exemplo.

Se o componente TSession e o componente TDatabase estiverem inativos qualquer demanda de uma

conexao a base de dados sempre devera ativar o componente TSession primeiro. sendo assim OnStartUp

sempre sera chamado em primeiro lugar.

Se estivermos utilizando apenas o componente default. criado automaticamente pelo Delphi. o evento

OnStartUp devera ser associado ao seu correspondente evento em tempo de execucao.

O evento OnStartUp sempre sera disparado quando a propriedade Active do seu componente TSession for

definido como True.

Metodo AddaAlias

AddAlias cria um novo BDE alias em tempo de execucao para ser utilizado com um servidor de banco de

dados para a sessao atual.

AddAlias necessita de tres parametros para ser utilizado. sao eles :

Nome - Nome do Alias sendo criado

Driver - Driver que sera utilizado por este novo Alias. obrigatoriamente este driver tem de ter

sido previamente instalado e configurado

Parametros - Um stringlist com todos os parametros para este novo alias, sempre um parametro por

linha dentro do stringlist

Apenas os componentes conectados a TSession poder utilizar o Alias criado com AddAlias.

Para criar um Alias dinamicamente utilize o seguinte codigo ...

procedure TForm1.AddLocalAlias;

var

  AliasInfo: TStringList;

begin

  AliasInfo :- TStringList.Create;

  try

    with AliasInfo do

    begin

      Add('SERVER NAME-C:\CSBASE\ARQUIVO1.GDB');

      Add('USER NAME-SYSDBA');

    end;

    Session1.AddAlias('DelphiCSBASE'.'INTRBASE'.AliasInfo);

  finally

    AliasInfo.Free;

  end;

end;

No exemplo acima criamos um novo alias temporario chamado DelphiCSBASE que deve utilizar o driver

do Interbase ( INTRBASE ) e todos os parametros relacionados em AliasInfo. foram definidos aPenas

dois parametros SERVER NAME que aponta para o arquivo "C:\CDBASE\ARQUIVO1.GDB". obviamente um

arquivo do Interbase. e USER NAME que recebeu SYSDBA que e' o user padrao

da instalacao do Interbase.

Este procedimento ao ser executado devera criar o Alias. entao ele estara disponivel para que a

aplicacao possa utilizado. podemos criar quantos Aliases julgarmos necessarios devemos apenas tomar

o cuidado de nao tentar criar o mesmo alias duas vezes. um erro ate' comum.

Se tentarmos criar o mesmo alias duas vezes. ou dois aliases com o mesmo nome uma exeception devera

ocorrer "Name not unique in this context." observe como esta mensagem de erro e'  sutilmente

correta. ela esta informando que o nome de alias que estamos tentando utilizar ja existe no

contexto atual. esta mensagem e'  mostrada desta forma porque o alias criado com o metodo AddAlias

nao esta definitivamente gravado no BDE. para isso devemos usar SaveConfigFile. mas esta presente

no momento dentro do contexto de trabalho da sua aplicacao.

Para evitar que este erro ocorra devemos deletar o Alias antes de tentar cria-lo novamente. para

isso devemos usar o comando DeleteAlias.

Metodo DeleteAlias

DeleteAlias apaga um alias presente na sessao atual. isso por si so nao quer dizer realmente que o

alias foi apagado. para garantir que um alias seja apagado definitivamente do BDE devemos usar

SaveConfigFile.

DeleteAlias pode apagar um alias criado dentro do BDE ou um alias criado unicamente dentro da

sessao atual.

DeleteAlias recebe um unico parametro que e' o nome do Alias que se deseja apagar. um alias que foi

criado dinamicamente sera automaticamente destruido quando a aplicacao for encerrada.

Session1.DeleteAlias('DelphiCSBASE');

Metodo IsAlias

Quando uma aplicacao necessita criar e apagar Aliases dinamicamente e' comum o desenvolvedor ter de

verificar se um determinado Alias ja existe antes de usa-lo. ou simplesmente se ele nao existe para

que seja devidamente criado antes de ser utilizado.

Em ambos os casos temos de determinar se um Alias deve ser criado. ou se ele ja existe.

Usamos IsAlias para isso.  este metodo retorna um valor booleano que devera ser analisado da

seguinte forma. se o valor for true quer dizer que o alias passado como parametro ja existe e nao

deve ser criado novamente. se o valor retornado for false nao existe um alias com o nome passado

como parametro.

Observe como devemos utilizar IsAlias em conjunto com DeleteAlias.

procedure VerificaDeleteAlias;

begin

  If (Session1.IsAlias('DelphiCSBASE')) then

    Session1.DeleteAlias('DelphiCSBASE');

end;

Metodo ModifyAlias

Existem situacoes em que o desenvolvedor pode encontrar a necessidade de alterar algum parametro de

um determinado Alias em tempo de execucao. embora um pouco raro tal caso pode ocorrer. sendo assim

podemos utilizar o metodo ModifyAlias para esta finalidade.

ModifyAlias recebe dois parametros para funcionar corretamente. o um string com o nome do Alias que

se deseja alterar e um TStrings com a lista do que se deseja alterar.

Obiamente nao podemos alterar o nome do alias ou o driver que estamos utilizando neste alias.

nestes dois casos temos de primeiro apagar o alias e criar um novo alias com as caracteristicas que

desejamos.

ModifyAlias deve ser utilizado de forma semelhante a AddAlias.

procedure ModificaAlias;

var

  AliasInfo: TStringList;

begin

  AliasInfo:- TStringList.create;

  try

    AliasInfo.Add('USER NAME-MARTINS');

    Session1.ModifyAlias('DelphiCSBASE'. AliasInfo);

  Finally

    AliasInf.free;

  end;

end;

Para que as modificacoes sejam permanentes e' necessario utilizar o metodo SaveConfigFile.

SaveConfigFile

Como pudemos ver nos metdos anteriores AddAlias. DeleteAlias. etc ... todas as mudancao processadas

por estes metodos sao efetuadas unicamente em memoria. isto ocorre porque o BDE trabalha da

seguinte forma:

Quando um aplicacao inicializa o BDE todas as configuracoes sao copiadas para a memoria. sendo

assim os metodos tratados ate aqui alteram a informaca que esta na memoria e nao no disco.

Para que possamos alterar definitiamente as informaces contidas no BDE devems gravar as alteraces

que fizems definitiamente no arqui de configuracao do BDE. e esta tarefa e' executada pelo metodo

SaveCnfigFile.