Newsgroup: it.comp.lang.visual-basic
Titolo: Adodb.Connection si chiude dopo 10', non idle!

 Server NT4SP4, con Sql-Server 7.0SP4.
Un applicativo (su W2003Server) si connette via Ado2.71.
Apre una connessione, estrae determinate informazioni, crea una tabella
temporanea #tab1, e sulla base di queste informazioni inizia una serie di
elaborazioni sul file system.
In occasione di determinate evenienze, esegue degli Insert sulla tabella
#tab1.
Grazie ad un log su file di testo, ho accertato che almeno ogni 10" avviene
un insert.
Eppure, con una regolarità impressionante, dopo 10' la connessione si chiude
(e nel log trovo l'errore che mi dice che la Adodb.Connection non è valida
nel contesto, quando cerco di impostare la ActiveConnection
dell'Adodb.Command per eseguire un insert).
Osservare che la connessione non è idle, cioè inattiva, in quanto ogni 10"
circa c'è un insert.
Non posso semplicemente testare lo stato della connessione e riaprirla,
perchè perderei la tabella temporanea #tab1, che alla fine della lavorata
sul file system mi serve per proseguire con altri lavori.
La connessione viene aperta con:
    CONNECTION.ConnectionTimeout = 5
    CONNECTION.CommandTimeout = 0
CONNECTION.ConnectionString="Provider=SQLOLEDB.1;Password=" & PWD &
";Persist Security Info=True;User ID=" & User & ";Initial Catalog=" & DBname
& ";Data Source=" & SQLServerName & " "
CONNECTION.Open
Mi chiedo se ci sia qualche parametro sul Server Sql7, o sul server NT (ma
non credo che l'AutoDisconnect di NT valga anche per le connessioni su
Sql-Server...).
Saluti
Alberto
--
Santo cielo, Magnum, si può sapere cos'è questo baccano?
Higgins, posso spiegarle...
Credo non sia necessario.
Zeus, Apollo, a voi...

 CONNECTION.Open
inutile chiedere se si esce dallo scope dell'oggetto connection, vero?
(mi rendo conto che scritta così è criptica, ma non riesco a fare di meglio)
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 inutile chiedere se si esce dallo scope dell'oggetto connection, vero?
La connection non è valida (ossia chiusa, quindi non assegnabile ad un
Command), non è nothing o non istanziata.
Comunque c'è una Function, chiamata da un timer, all'interno della quale
viene aperta la connection, e poi vengono chiamate in sequenza le diverse
funzionalità, passando byref l'oggetto connection.
L'errore si presenta in un loop ricorsivo (sostanzialmente una scandagliata
di sottocartelle e files), dopo che la stessa function richiamata ha già
girato, che so, mille volte, dopo 10' la connection non è più valida...
Ciao
Alberto

 ha scritto nel messaggio
news:2p67i8F...@uni-berlin.de...

non mi suona.
non è che, banalmente, da qualche parte per qualche motivo non
chiudi/distruggi le connection precedenti e quindi la func semplicemente non
può crearti quella nuova per superamento dei client disponibili?
ciao
ugo

 Command), non è nothing o non istanziata.
giusto.
ho fatto un'osservazione impropria.



La Connection viene aperta ad inizio funzione.
Poi viene utilizzata in diversi loop. Questi loop lavorerebbero, se non ci
fossero problemi, per un paio d'ore.
Invece, dopo 10', e dopo che la connection č giŕ stata usata n volte senza
problemi, ad un certo punto fallisce.
All'interno dei loop, la connection viene usata cosě:
Set Ado_Cmd.ActiveConnection=Ado_Ccn
Ado_Cmd.Commandtext="Insert....."
Ado_Cmd.Execute
L'errore avviene sul Set, nonostante le stesse righe di codice abbiano giŕ
eseguito qualche migliaia di volte.
I Command sono sincroni.
Comunque, c'č un elemento nuovo.
Ho tolto il Set. Cioč, ho detto, se la Connection rimanesse aperta, basta
impostarla come ActiveConnection del Command una sola volta, poi cambio ad
ogni giro il CommandText ed eseguo. Il set era finito lě perchč inizialmente
eseguivo un test sullo stato della Connection, al bisogno la riaprivo,
quindi dovevo riassegnarla al Command.
Bene, dicevo, ho tolto il Set: il sw sta girando da circa 45' senza errori.
Aspettiamo ancora un po', poi vediamo l'esito...
Ciao
Alberto

 Bene, dicevo, ho tolto il Set: il sw sta girando da circa 45' senza
errori.
allora la stessa considerazione precedente potrebbe essere fatta per
l'oggetto command, no?
il fatto che senza rieseguire il set l'errore non si verifica sembra
confermare l'ipotesi di oggetti command non correttamente
inizializzati/distrutti.
facci sapere.
ciao
ugo

 inizializzati/distrutti.
Non ti seguo al 100%...
Se utilizzo lo stesso oggetto Adodb.Command, senza reimpostare niente nei
vari giri, e questo funziona, significa che l'oggetto rimane correttamente
istanziato ed impostato. L'unica cosa che ho modificato è stato un apicino
di commento davanti al Set.
Piuttosto, mi viene da pensare che qualche cosa, chissà cosa, si intrippa se
l'oggetto command viene impostato troppe volte, oppure se l'ActiveConnection
viene riscritta troppe volte, oppure... boh.
Aspettiamo ancora, la bestia sta girando...
Alberto

 di commento davanti al Set.
questo fa pensare che restino "appese" delle connection a oggetti command
non distrutti e/o riciclati e si raggiunga così, col tempo, i limite dei
client.
Potrebbe essere interessante come test downgradare le licenze server fino a
1 o il n° di client contemporanei che ti servono per 1 sola sessione
dell'applicativo... e vedere che succede...
ciao
ugo