OS MYSQL DE PLANTAO
Citação:Ta meus amigos, até que entendi as soluçoes apresentadas por voces, mas veja bem eu nao entendi muito bem a logica .. eu vou dar o select em qual tabela para verificar a conexao ? dim sql as string:
Eu também utilizo a forma do JANDER, a mais de 3 anos, foi a melhor forma que encontrei.
sql= [Ô]select 1[Ô]
coloca ela dentro do timer..
ficou meio vago para meu entendimento, seria uma tabela menor ?
bom colega esta dica do colega jander eu nunca testei, mas de meu ponto de vista o ideal seria vc dar um ping no seu servidor para saber se está conecta-do ou não
ou seja quando apresentar o erro trate ele como dito anteriormente, neste tratamento acione um timer que dará um ping de tantos em tantos segundos até a conexão se reestabelecer, veja o exemplo
TENTE ESTE CÓDIGO
ou seja quando apresentar o erro trate ele como dito anteriormente, neste tratamento acione um timer que dará um ping de tantos em tantos segundos até a conexão se reestabelecer, veja o exemplo
Private Declare Function Ping Lib [Ô]iphlpapi[Ô] _
Alias [Ô]#65[Ô] (ByVal pInternetProtocol As Long, pNumberOfCalls As Long, _
ByVal pMaxNumberOfCalls As Long, lTime As Long) As Long
Private Declare Function ConvertStringToIP Lib [Ô]wsock32[Ô] _
Alias [Ô]#10[Ô] (ByVal stoip As String) As Long
Function MyPing(sIPAddr As String) As Boolean
Dim IP As Long, pNumCalls As Long, lTime As Long
IP = ConvertStringToIP(sIPAddr)
MyPing = (Ping(IP, pNumCalls, 15, lTime) = 1)
End Function
Private Sub Timer1_time()
Dim Result As Boolean
Result = MyPing([Ô]72.14.204.147[Ô]) [ô]este ip é de um site de busca famoso coloque aqui o ip de seu servidor
If Result = True Then
MsgBox [Ô]conexão reestabelecida[Ô]
Timer1.Enable = False
Else
MsgBox [Ô]Servidor ainda não responde[Ô]
End If
End Sub
TENTE ESTE CÓDIGO
Bem....
A melhor opção é aquela que melhor se adapta ao seu sistema sem a necessidade de grandes mudanças.
PORéM, tecnicamente falando alguns procedimentos são considerados BOAS PRÃTICAS.
Se você quer deixar seu sistema de acordo com o que pede as BOAS PRÃTICAS então você deve :
ABRIR_CONEXÇÃO
EXECUTAR_QUERY
FECHAR_CONEXÃO
Ao abrir a conexão você estará automaticamente pingando no servidor, e poderá tratar qualquer erro que ele possa retornar.
Na execução da Query você também pinga e pega qualquer erro, caso ocorra.
Tenha o cuidado de SEMPRE [Ô]matar[Ô] suas conexões, pois assim fazendo você ganha em DESEMPENHO com o servidor.
Pingando a cada 14 ou 15 segundos é o tempo que você levaria para ABRIR_CONEXÃO ,EXECUTAR_QUERY GIGANTE, FECHAR_CONEXÃO, so que com um diferencial : VOCÊ SÓ UTILIZA O SERVIDOR SE REALMENTE FOR EXECUTAR ALGO.
Caso o usuário levanta-se para ir ao banheiro, e aproveita para tomar um café, descansar, esticar as pernas e fique digamos 5 minutos(que é pouco tempo). Você terá executado 20 conexões ao servidor somente para ver se ele está ou não On Line.
Parece pouco, mas se ele se levantar 5 vezes e fizer isso já serão 100 conexões, e isso se ele ficar apenas 5 minutos.
Alguns requisitos para as tais BOAS PRÃTICAS.
- Como citado pelo amigo Jesuel, procure executar querys objetivas, sem retornos de grande quantidades de dados.
- Procure explorar mais os recursos do MySql, como por exemplo as Stored Procedures, Functions, Triggers.
- Querys que não retornam dados(update, insert, delete) execute-as no servidor(utilizando Stored Procedures).
- Querys que retornam grandes quantidade de dados utilize filtros nos formulários.
E por aà vai.
A melhor opção é aquela que melhor se adapta ao seu sistema sem a necessidade de grandes mudanças.
PORéM, tecnicamente falando alguns procedimentos são considerados BOAS PRÃTICAS.
Se você quer deixar seu sistema de acordo com o que pede as BOAS PRÃTICAS então você deve :
ABRIR_CONEXÇÃO
EXECUTAR_QUERY
FECHAR_CONEXÃO
Ao abrir a conexão você estará automaticamente pingando no servidor, e poderá tratar qualquer erro que ele possa retornar.
Na execução da Query você também pinga e pega qualquer erro, caso ocorra.
Tenha o cuidado de SEMPRE [Ô]matar[Ô] suas conexões, pois assim fazendo você ganha em DESEMPENHO com o servidor.
Pingando a cada 14 ou 15 segundos é o tempo que você levaria para ABRIR_CONEXÃO ,EXECUTAR_QUERY GIGANTE, FECHAR_CONEXÃO, so que com um diferencial : VOCÊ SÓ UTILIZA O SERVIDOR SE REALMENTE FOR EXECUTAR ALGO.
Caso o usuário levanta-se para ir ao banheiro, e aproveita para tomar um café, descansar, esticar as pernas e fique digamos 5 minutos(que é pouco tempo). Você terá executado 20 conexões ao servidor somente para ver se ele está ou não On Line.
Parece pouco, mas se ele se levantar 5 vezes e fizer isso já serão 100 conexões, e isso se ele ficar apenas 5 minutos.
Alguns requisitos para as tais BOAS PRÃTICAS.
- Como citado pelo amigo Jesuel, procure executar querys objetivas, sem retornos de grande quantidades de dados.
- Procure explorar mais os recursos do MySql, como por exemplo as Stored Procedures, Functions, Triggers.
- Querys que não retornam dados(update, insert, delete) execute-as no servidor(utilizando Stored Procedures).
- Querys que retornam grandes quantidade de dados utilize filtros nos formulários.
E por aà vai.
Gostei .. foxman, voce falando em relação a triggers, storage.. etc.. em relação a desempenho propriamente dito, e melhor utilizaçao de storage para manipular os dados diretamente, mas o desempenho é tão gigantesco assim? tipo.. a diferença e tao grotesca? eu tenho algumas storages se vcs baterem o martelo eu migro todas minhas telas.. utilizando apenas storage
Não chega a ser grotesca não, mas se formos fazer uma comparação, é como se você executasse a query diretamente no servidor. Agora teste fazer um update de um campo em uma tabela que tenha 50.000 registros diretamente no servidor e depois faça o mesmo através do seu sistema, ambos lhe retornaram um tempo diferente para executar a mesma query.
Mas a questão do seu tópico nem chega a ser DESEMPENHO, seu tópico trata de TimeOut. Se você pode setar as variáveis do seu servidor aumente o connect_timeout, e caso tenha grande tráfego de dados no mysql aumente também o max_allowed_packet, acredito que talvez consiga contornar o problema alterando essas variaveis.
Mas a questão do seu tópico nem chega a ser DESEMPENHO, seu tópico trata de TimeOut. Se você pode setar as variáveis do seu servidor aumente o connect_timeout, e caso tenha grande tráfego de dados no mysql aumente também o max_allowed_packet, acredito que talvez consiga contornar o problema alterando essas variaveis.
me conecto como o XXXangelsxxx me passou uma vez.. o que vcs mudariam nessa conexao?
Public Function Conecta(ByVal Valor As Boolean)
On Error GoTo ErrorLine
If Valor = True Then
DoEvents
Set Conexao = New Connection
SERVIDOR = [Ô][Ô] & ReadINI([Ô]Conexao[Ô], [Ô]SERVIDOR[Ô], App.Path & [Ô]\ConfigServidor.ini[Ô])
BASEDEDADOS = [Ô][Ô] & ReadINI([Ô]Conexao[Ô], [Ô]BancoDeDados[Ô], App.Path & [Ô]\ConfigServidor.ini[Ô])
PORTA = [Ô][Ô] & ReadINI([Ô]Conexao[Ô], [Ô]PORTA[Ô], App.Path & [Ô]\ConfigServidor.ini[Ô])
USUARIO = [Ô][Ô] & ReadINI([Ô]Conexao[Ô], [Ô]USUARIO[Ô], App.Path & [Ô]\ConfigServidor.ini[Ô])
DCSENHA = [Ô][Ô] & ReadINI([Ô]Conexao[Ô], [Ô]SENHA[Ô], App.Path & [Ô]\ConfigServidor.ini[Ô])
SENHA = [Ô][Ô] & Cr.Descripitografia(DCSENHA)
CON_STR = [Ô]DRIVER={MySQL ODBC 5.1 DRIVER};[Ô] _
& [Ô]Server=[Ô] & SERVIDOR & [Ô];[Ô] _
& [Ô]Port=[Ô] & PORTA & [Ô];[Ô] _
& [Ô]Database=[Ô] & BASEDEDADOS & [Ô];[Ô] _
& [Ô]UID=[Ô] & USUARIO & [Ô];[Ô] _
& [Ô]PWD=[Ô] & SENHA & [Ô];[Ô] _
& [Ô]OPTION=[Ô] & 1 + 2 + 8 + 32 + 2048 + 16384
With Conexao
.CursorLocation = adUseClient
.ConnectionString = CON_STR
.Open CON_STR
End With
Else
Conecta True
If Conexao.State = 1 Then Conexao.Close
Set Conexao = Nothing
End If
Exit Function
ErrorLine:
MsgError
End Function
Citação::
Gostei .. foxman, voce falando em relação a triggers, storage.. etc.. em relação a desempenho propriamente dito, e melhor utilizaçao de storage para manipular os dados diretamente, mas o desempenho é tão gigantesco assim? tipo.. a diferença e tao grotesca? eu tenho algumas storages se vcs baterem o martelo eu migro todas minhas telas.. utilizando apenas storage
Dependendo do ambiente, a diferença é mÃnima mesmo. Acredito que uma das maiores vantagens de trabalhar assim é na arquitetura do projeto, pois vc consegue fazer com que sua aplicação seja multibanco de uma forma mais transparente, e em alguns casos, vc teria que apenas mudar a string de conexão. Embora colocando as DMLs no seu código vc possa ter um desenvolvimento multibanco, as vezes podemos esbarrar numa função interna especÃfica do próprio banco e terÃamos que sair caçando no código essas funções e substituÃ-las.
Uma das vantagens de uso de SP é que apenas os dados dos campos trafegam pela rede e a SP que é pré-compilada, recebe os dados e os trata. Se vc manda toda a instrução SQL, ela vai ter que ser analisada pelo SGBD e depois executada. Claro que se o ambiente tem pouca atividade isso não pesa muito (ou praticamente nada), mas num ambiente crÃtico com certeza fará toda diferença. E SPs ajudam a evitar SQL injections. Em aplicações web é muito importante.
Nesses dias até surgiu uma discussão se os ORMs estariam decretando o fim das SPs.
http://devbrasil.net/group/adonet/forum/topics/chegou-ao-fim-o-uso-de-stored
VILANOVA.
coloca esse código dentro do timer
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rsUser.Open [Ô]select 1[Ô], conn, adOpenKeyset, adLockOptimistic
isso é como ele estivesse dando um ping no servidor..
caso sua duvida já esteja respondida, favor encerra o tópico.
coloca esse código dentro do timer
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rsUser.Open [Ô]select 1[Ô], conn, adOpenKeyset, adLockOptimistic
isso é como ele estivesse dando um ping no servidor..
caso sua duvida já esteja respondida, favor encerra o tópico.
Tópico encerrado , respostas não são mais permitidas