Newsgroup: it.comp.lang.delphi
Titolo: zquery in eccezione blocca le altre ?

Il problema che ho incontrato è piuttosto fastidioso.
Premetto che l'eccezione durante l'uso di una zquery (ZEOS 6.1.5 + D 7 + 
MySql 4.0.24) è senza dubbio colpa di qualche mia disattenzione.
Capita questo:
dopo aver tentato di accedere ai recorset di una zquery si scatena un 
eccezione (campi inesistenti, conversioni in Currency impossibili etc).
Diciamo che la zquery dove si è verificato un problema (Eccezione o sia 
bloccato etc..) si chiami zq1, si può verificare che un'uso successivo 
in un'altra procedura di una diciamo zq2 non sia possibile e scateni 
eccezioni ?
Bhè a me pare capitare proprio questo. Non sono riuscito a scovare il 
baco ma sembra che se una zqX in qualche modo si pianti, pianta anche 
tutte le altre zqYZ esistenti.
In questo caso quale soluzione dovrei adottare ?
Una disconnessione dell'oggetto connection potrebbe risolvere tutti i 
problemi sui componenti ZQ ? In questo caso per assicurarmi che non 
avvenga mai un problema dovrei disconnettere e riconnettere sempre...
Daniele

 avvenga mai un problema dovrei disconnettere e riconnettere sempre...
Non è fattibile per molte ragioni, la prima delle quali è che scalerebbero
le connessioni TCP in attesa di terminazione sforando ben presto il numero
massimo del sistema operativo e poi perché disconnettersi e riconnettersi
in continuazione fa degradare notevolmente le performance.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Questo mi fà pensare ad un altro componente che lavora con le 
connessioni tcp. L' IdTCPServer !
Quindi ammettendo il caso che le query eseguite siano tutte corrette, è 
possibile che il TCPServer in qualche modo vada ad interferire con le 
comunicazioni TCP e quindi blocchi anche le ZQuery ?
Qui di seguito riporto il codice che utilizzo per ricevere dati con 
IdTCPServer :
procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
Var
  Dati       : string;
  risp       : string;
begin
try
     Dati := AThread.Connection.ReadLn(#13#10,1000);
     if (Trim(Dati) = '') then begin
 
       try
         AThread.Connection.DisconnectSocket;
         except
           ADDLOG('IdTCPServer1Execute - 0A','Errore su 
disconnessione','Dati:-'+Trim(Dati)+'-',True);
       end;
     	ADDLOG('IdTCPServer1Execute 0B','Dati:-'+Trim(Dati)+'-','(1)',False);
       Exit;
     end;
   	except
   	//Esco perchè non posso continuare senza dati corretti
 
       try
         AThread.Connection.DisconnectSocket;
         except
           ADDLOG('IdTCPServer1Execute - 1A','Errore su 
disconnessione','Dati:-'+Trim(Dati)+'-',True);
       end;
    	 	ADDLOG('IdTCPServer1Execute - 1B','Err in ric. dati 
Dati:'+Trim(Dati)+'-','-',True);
	exit;
   end;
       if (Dati <> '') then begin
         risp := 'OK';
         end
         else begin
           risp := 'NOK';
       end;
       ZQComandaOnData.Close;
       try
         AThread.Connection.WriteLn(risp);
         AThread.Connection.DisconnectSocket;
         if risp = 'NOK' then Exit;
         except
          ADDLOG('IdTCPServer1Execute - 2','AThread.Connection.WriteLn 
su dati:-'+Trim(Dati)+'-',' Risposta al client: '+ risp,True);
       end;
end;
La domanda è questo codice è corretto ? cioè funziona (è il solo 
presente) ma potrebbe essere parte in causa del problema numero massimo
connessioni TCP ? E se si, quale è il codice corretto per utilizzare 
questo componente in base al servizio di semplice ricezione e invio di 
risposta ?
Grazie della risposta in ogni caso.
Daniele

 comunicazioni TCP e quindi blocchi anche le ZQuery ?
Non so perché ti serva un componente TIdTCPServer all'interno della tua
applicazione e non conosco l'uso che ne fai, ma penso sia improbabile che
interferisca con le ZQuery.


 
Sono alla ricerca di un metodo affidabile per comunicare con dispositivi 
wireless. Al momento non mi interessa la sicurezza ma solo la 
affidabilità e la stabilità. Il db interviene nella lettura e scrittura 
di dati verso/da i dispositivi.
Ho notato che le ZQuery in caso di disconnessione riattivano la 
connessione stessa. Se un oggetto ZQuery è chiuso/aperto e si esegue una 
SQL di modifica o di lettura questo viene chiuso/riaperto 
automaticamente permettendo l'aggiornamento del recordset in memoria.
La timeout del MySql è impostata 28800 sec (8 ore) quindi non può essere 
questo il problema, in quanto salta fuori nel giro di 1 o 2 ore al massimo.
La domanda sul TCP è dovuta ad un dubbio sul come veniva usato. Mi 
confermi quindi che il codice è corretto ? Cosa può scatenare 
un'eccezione nell'uso della writeLn del tcp nel codice riportato ?
Dimenticavo la ADDLOG è una mia procedura che traccia l'errore in un file.
Daniele

 automaticamente permettendo l'aggiornamento del recordset in memoria.
Forse confondi l'attivazione di una connessione con l'apertura di un
dataset.
Sono due concetti differenti: attivare una connessione è un'operazione
generalmente dispendiosa in termini di tempo e risorse.  Riaprire un
dataset, invece, significa semplicemente reinvocare lo statement SQL di
select.
Se invece non stai confondendo, non capisco che cosa tu intenda con "in
caso di disconnessione riattivano la connessione stessa".  E'
un'iniziativa un po' azzardata da parte del componente dataset.


 
Intendo proprio questo. Ammettiamo di avere una connection zeos ZConn1
e una ZQuery ZQ1
se ZConn1.Connected := False e eseguo ZQ1.Open si attiva la connesione.
Impostando le proprietà opportune in ZConn1 e ZQuery (autocommit, 
requestlive etc) si attiva la connessione.
Il mio sospetto che contasse qualcosa il TCPserver nel blocco della ZQ1 
derivava dal fatto che anche ZConn1 lavora in tcp su una porta 
dichiarata che è quella del server MySql. Però il TCPServer ha anch'esso 
una porta dichiarata. Io spero proprio che non sia un problema legato 
tra i due componenti. Il fatto è che le eccezioni si verificano in 
situazioni che normalmente funzionano regolarmente.
Daniele