Newsgroup: it.comp.lang.delphi
Titolo: strano comportamento di una query

Ciao,
	vorrei chiedervi un consiglio su quanto segue.
PREMESSA:
Un po' di tempo fa mi imbattei nel *famigerato* problema di prestazioni 
dell'accoppiata BDE-MsSqlServer: eseguire l'istruzione "Open" di una 
TQuery senza averne chiusa una precedente a carico della stessa 
connessione causa la lettura di tutti i dati della prima query 
determinando un ritardo nell'esecuzione della seconda.
Appurato che non c'erano soluzioni a riguardo, fui costretto ad 
implementare un meccanismo alternativo per alleviare almeno un po' i 
problemi di prestazioni.
Approntai quindi un sistema di gestione di connessioni temporanee, 
istanziate a run-time e dedicate all'esecuzione di query con molti dati 
di ritorno, cosi' da isolare le eventuali successive operazioni di lettura.
PROBLEMA ATTUALE:
Il problema di prestazioni sembra risolto ma, come spesso succede, ne e' 
  subentrato un altro. Le query associate alle connessioni temporanee 
ritornano set di dati "inconsistenti" nel caso di utilizzo di costanti 
"data" nello statement di selezione.
Mi spiego. Supponiamo che lo statement di selezione della query sia:
	select * from Tabella1 where Data >= '12/02/2005' and Data <= '25/12/2005'
ebbene, la sua esecuzione a carico della connessione principale, ritorna 
un set di 'n' righe, mentre quella a carico della connessione temporanea 
dedicata ritorna 0 righe.
Aggiungo un pezzo di codice sorgente per rendere il tutto piu' chiaro:
	<code>
 
	// Una connessione temporanea per ogni apertura di query 			// ambiente.
 
   	// rimuove una eventuale precedente connessione temporanea 			// 
dedicata alla TQuery corrente
   	if ( temporaryConnectionExist(qryFilter) ) then
     		remTemporaryConnection(qryFilter);
	// istanzia una nuova connessione temporanea 					// dedicata alla 
TQuery corrente
   	qryFilter.DatabaseName := 							 
getNewTemporaryConnection(qryFilter).DatabaseName;
	(*
	// commentando le istruzioni precedenti e utilizzando la 			// 
connessione principale => tutto OK:
	qryFilter.DatabaseName := MyDB.DatabaseName;
	*)
   	qryFilter.SQL.Clear;
   	qryFilter.SQL.Text := sSQL;
   	try
     		qryFilter.Open;
   	except
     	on E: Exception do
     	begin
       		// etc.
     	end;
	</code>
Aggiungo inoltre che quando lo statement di selezione non contiene 
costanti di tipo data, le query a carico delle connessioni temporanee 
dedicate sembrano funzionare correttamente, al pari delle altre.
Qualcuno ha un idea?
grazie,
baba.

A me succedeva così usando ado e access, la data memorizzata nella 
tabella conteneva anche l'ora, per cui metto :
dal 01/01/2004 00.00   al 31/01/2004 23.59
e funziona. Magari è questo anche per te.
Ciao.
Inviato da 
www.mynewsgate.net

Qualcuno ha un idea?
Formato date errato?
in MsSQL normalmente, almeno che non vi siano dei settaggi ambientali
particolari, il formato è '2004-12-31 22:10:54.000', non è che la
connessione temporanea usa dei settaggi diversi rispetto alla
connessione "persistente" e conseguentemente, dei formati data
diversi?
-- 
Ore 18.30: premo invio.

 
Ciao Massimo,
	intanto grazie per la risposta.
In effetti avevo considerato l'ipotesi, ti spiego.
Per evitare che la localizzazione di MSSql Server diventi un problema 
abbiamo creato una procedura che, invocata dopo l'apertura della 
connssione con il DB, imposta la lingua ed il formato di date per la 
sessione relativa. I due comandi inviati al server sono:
	SET LANGUAGE 	us_english
	SET DATEFORMAT	mdy
Questo ci permette di assumere che la connessione "persistente" utilizza 
sempre lo stesso formato e lingua, indipendentemente dalla impostazioni 
del server.
Quando ho implementato il meccanismo delle connessioni temporanee ho 
fatto ovviamente attenzione a mantenere inalterato il principio, 
invocando quindi la suddetta procedura dopo l'apertura di ogni nuova 
connessione "temporanea".
Quindi, ripeto, avevo considerato l'ipotesi da te avanzata, ma l'avevo 
anche subito scartata, confortato dal ragionamento di cui sopra.
E qui l'errore.
La procedura suddetta, infatti, eseguiva i comandi di impostazione 
lingua e formato date *SEMPRE* sulla connessione "permanente"!
Ecco perche' le query eseguite a carico delle nuove connessioni 
"temporanee" e contenenti costanti di tipo data venivano effettuate con 
un formato data diverso e restituivano quindi un recordset inconsistente.
Comunque c'hai preso.
grazie,
baba.