Newsgroup: it.comp.appl.access
Titolo: Errore ODBC - Timeout query scaduto

Buongiorno,
non sicuro di essere sul NG giusto (non sò se il problema dipende da
access, sql server oppure altro).
Ho un FE con access 2000 (che "gira" sia su win XP che win 2000, con
access 2002 e 2000) collegato a sql server 2000.
Le istruzioni incriminate sono:
qry="UPDATE TAGLIANDI SET RISTAMPE = " & XX & " WHERE ID=" & ID & "
AND ANNO=" & ANNO
docmd.runsql qry
Le variabili sono certe (nel senso che non vengono passati parametri
non compatibili) e sono numeri interi.
Ogni tanto, apparentemente con modalità casuale, l'UPDATE non avviene
e mi ritorna il seguente errore:
Errore di run-time '3157'
ODBC: operazione di UPDATE non riuscita su tabella collegata
'TAGLIANDI'
[Microsoft][ODBC SQL Server Driver] Timeout query scaduto. (#0)
Qualche idea?

Qualche idea?
Per caso usi l'UPDATE sulla stessa tabella su cui prima hai fatto una INSERT o
anche una semplice SELECT?
-- 

 anche una semplice SELECT?
All'interno del controllo specificato non faccio nessuna operazione
prima dell'UPDATE
La SELECT avviene dopo quando seleziono i dati da stampare.
QRY_BASE = "SELECT * FROM TAGLIANDI WHERE ID=" & Me.ELC1.Column(0) & "
AND ANNO=" & Me.ELC1.Column(1)
DoCmd.OpenReport "REP_TAGLIANDO", acViewNormal
(nell'apertura del report viene impostata la QRY_BASE)

altre idee?
dove postare sul ng di sql?

dove postare sul ng di sql?
Avevo giŕ postate 2 volte....ma evidentemente c'č qualche problema.....
Riassumo. I timeout succedono essenzialmente per 2 motivi: o l'operazione č
titanica (allora basta allungare il timeout o ripensare la procedura) oppure
ci sono dei lock nel mezzo. SQL server ha tutta una sua gestione dei lock che
sarebbe bene conoscere (io per primo!!!!) per sapere come meglio agire.
Aggiungi che Jet potrebbe decidere di aprire + connessioni contemporanee per
questioni prestazionali. Questo č un comportamento non trasparente, nel senso
che non lo sai se e quando lo fa.....Possibili soluzioni: usi ADO e non DAO.
Cosě controlli tutto: connessioni, livello di isolamento.....Confezioni una
query pass-through che viene eseguita lato server SENZA elaborazioni da parte
di jet. Usi le stored-procedure...che sarebbe di gran lunga la soluzione
migliore (atomicitŕ garantita, zero traffico di rete, gestione completamente
delegata al server.....). Di solito č sufficente ripensare le procedure per
non cadere in questi casi.....l'upgrade al completo client-server č
chiaramente la soluzione ideale IMHO
-- 

 di jet.
ho convertito tutte le query "normali" in query pass-through:
l'errore si ripresenta ugualmente anche se con minor frequenza
Se imposto il timeout = 0 ?
Può essere utile?


Timeout a 0 significa tempo illimitato di esecuzione (non di connessione).
Cmq se appena mille record inchiodano sql c'è qualcosa che devi rivedere 
nella struttura del db e/o dello statement.
Ciao
-- 
Daniele
Rispondere scartando OneEDP, spam e 32

 nella struttura del db e/o dello statement.
è quello che stavo cercando di capire/fare ...
esiste un strumento di analisi più appropriato?

dimenticavo:
client windows seven pro 64 bit
cluster win 2000 srv e sql 2000


SQL Profiler di tutto di più.
Oppure da Management Studio attivi le statistiche io 
http://msdn.microsoft.com/it-it/library/ms184361.aspx
 ed esegui lo 
statement sa ssms.
