Caro Luiz Henrique,

Mesmo suas aplicações sendo extensas sugiro que você faça um esforço para
verificar SqlConnects sem SqlDisconnects. Existem várias estratégias e você
pode até mesmo usar a mais simples de todas: Coloque cada desenvolvedor seu
para analisar um form por semana (com todas as suas funções, eventos e
objetos de negócio que forem utilizados). Acho isso razoável. Se vc colocar
4 desenvolvedores nisso, em um mês terá mapeado aproximadamente 16 forms.
Não é ótimo, mas já é um começo. Inicie pelos forms mais complexos onde é
bem provável que estejam as rotinas mais delicadas - com maior número de
ocorrências.

Deixe-me explicar melhor um ponto que eu citei: quando falei sobre não
deixar conexões abertas quando a aplicação estiver em estado de espera de
alguma ação do usuário, quis dizer que as cargas iniciais de combos (suas
descrições e suas PKs), tabelas e outras informações que necessitem ser
carregadas no SAM_Create/SAM_CreateComplete dos toplevels devem ser feitas
com uma única conexão. Após tudo ser carregado vc pode desconectar esse
único handle do banco.

Conforme vc falou, imagine uma tela com um combo/list box que precisa ser
validado no momento da inclusão/alteração. Pois bem, assim que vc acionar o
método para realizar a atualização, ele faria a conexão, validaria tudo o
que precisa ser validado e em seguida procederia com a operação de
atualização/inclusão. Após terminar essa operação a desconexão seria feita.

Entendo que não é tao simples assim. Algumas aplicações podem se tornar
bastante complexas e difícil de se fazer isso.

Mas não sejamos tão radicais. Imagino que outra alternativa seria você ter
apenas dois handles conectados sempre por aplicação:

- um ghSql (declarado no Global Declarations) que permaneceria conectado
sempre, para inclusões/alterações e selects que retornem apenas uma linha.
Esse handle seria o handle que sua janela de login conecta. Seria
desconectado no SAM_AppExit.

- um hSqlLocal (declarado na sua classe de form ou no próprio form caso vc
não use classes) Este handle local do form seria conectado no SAM_Create do
form e desconectado no SAM_Close do mesmo. assim vc garante que nunca fica
handle conectado desnecessariamente. Este handle local vc utilizaria para
quando necessitasse navegar por result sets.

É óbvio que se vc tiver 10 telas abertas simultaneamente vc terá 10 handle
conectados, o que não é uma boa, na minha forma de ver. Mas acho difícil vc
ter 10 telas abertas ao mesmo tempo. De qualquer forma, esta solução é bem
mais simples do que controlar uma coleção de handles sql.

( Lembre-se de que se você fizer alguma operação com banco de dados com um
hSql1, enquanto percorre um result set carregado num hSql2, o conteúdo do
result set será perdido a menos que vc diga ao SQLWindows que preserve o seu
handle hSql2. )


Lairton.






Em 29/05/07, Rodrigo Scarano - Target Sistemas <[EMAIL PROTECTED]>
escreveu:

 Beleza Luizão,



Valeu pelas dicas.



[]s, Rodrigo.



-----Mensagem original-----
*De:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Em
nome de *Luiz Henrique da Cruz
*Enviada em:* terça-feira, 29 de maio de 2007 15:59
*Para:* [email protected]
*Assunto:* RES: [sqlwin] Qtde de Handles



Rodrigo,



Nós temos um esquema meio diferente de conexão, temos um vetor que
armazena o handle Sql a cada nova conexão com banco de dados.

E nunca desconectamos o handle Sql, apenas sinalizamos que o handle Sql
está disponível para uso.

Desta forma, quando é chamada a função DBConnect, primeiro verificamos se
tem handle conectado disponível, e se não tiver, é feito o SqlConnect (e
consequentemente, armazenado no vetor)



No seu caso, vc deverá retirar a string na função de disconnect, pois a
conexão será realmente finalizada.



[]s,

*LUIZ HENRIQUE DA CRUZ
*Centura Developer
[EMAIL PROTECTED] * <[EMAIL PROTECTED]>
ASM Soluções em RH
Rua Álvares Penteado, 203
Cep: 01012-001 - São Paulo - SP
*Tel*: +55 (11) 3526-5206
*Fax*: +55 (11) 3526-5218

*www.asm.com.br* <http://www.asm.com.br/>


  ------------------------------

*De:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Em
nome de *Rodrigo Scarano - Target Sistemas
*Enviada em:* terça-feira, 29 de maio de 2007 15:34
*Para:* [email protected]
*Assunto:* RES: [sqlwin] Qtde de Handles



Luiz,

No seu caso, precisa retirar a string do vetor após um "SqlDisconnect",
correto?



[]s, Rodrigo.



-----Mensagem original-----
*De:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Em
nome de *Luiz Henrique da Cruz
*Enviada em:* terça-feira, 29 de maio de 2007 11:39
*Para:* [email protected]
*Assunto:* RES: [sqlwin] Qtde de Handles



Fala Rodrigão, blz?



Nós também estamos com o mesmo problema, em algum ponto da aplicação esta
fazendo a conexão com o banco de dados, e não está desconectando, e quando
atinge o numero de 100 conexões, apresenta esse erro.



A solução que tivemos para tentar identificar o erro, foi colocando o nome
dos handles Sql em um vetor, e quando atinge um numero alto de conexões, é
gerado um arquivo com os nomes dos handles.



Para isso, fiz um programinha, que varre um APT, e passa mais um parâmetro
string com o nome do handle Sql na função de conexão, e armazena num vetor,
para posteriormente gravar num arquivo.

Exemplo:

Antes:  DBConnect ( hSqlLeRPProgPer )

Depois: DBConnect ( hSqlLeRPProgPer, 'hSqlLeRPProgPer' )



Essa foi a única forma de mapear o erro, caso o handles conectados tenham
nomes distintos.



Espero ter ajudado,



Abraços,

*LUIZ HENRIQUE DA CRUZ
*Centura Developer
[EMAIL PROTECTED] * <[EMAIL PROTECTED]>
ASM Soluções em RH
Rua Álvares Penteado, 203
Cep: 01012-001 - São Paulo - SP
*Tel*: +55 (11) 3526-5206
*Fax*: +55 (11) 3526-5218

*www.asm.com.br* <http://www.asm.com.br/>


  ------------------------------

*De:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Em
nome de *Rodrigo Scarano - Target Sistemas
*Enviada em:* terça-feira, 29 de maio de 2007 11:14
*Para:* Centura List
*Assunto:* [sqlwin] Qtde de Handles



Bom dia a todos,



Hoje utilizamos a conexão com o banco de dados utilizando um "Sql Handle"
e a função "SqlConnect" para conectar-se com o SQL Server 2000. Estamos com
um erro de "No SQL Cursors Remaining" que pelo provavelmente foi causado por
uma quantidade de "Handles" que já estão abertas na máquina. Gostaria de
saber se existe alguma função do "Centura" que retorna a quantidade de
"Handles" abertas para podermos depurar o problema.



Att,







*Rodrigo Scarano*
*Target Sistemas*
http://www.targetsis.com.br/
[EMAIL PROTECTED]






--

Lairton N de Almeida Jr.
[EMAIL PROTECTED]

Responder a