Timeout maschere filtrate con tabelle ODBC/SQL Server

[Davide La Mantia]

Ciao a tutti,
in una mia applicazione gestionale, realizzata con tabelle di SQL Server collegate tramite ODBC, accade che quando apro una maschera utilizzando un filtro, le query di aggiornamento lanciate dalla maschera o anche la semplice modifica dei record della sottomaschera non vadano sostanzialmente mai a buon fine, ma viene restituito un timeout dopo 60 secondi, così anche se cerco di eliminare un record dalla sottomaschera.

Se rimuovo i filtri, e posiziono la maschera sullo stesso record, tutto funziona perfettamente, aggiornamenti, eliminazioni e query di aggiornamento.

Onestamente ho provato di tutto, ma l'unica cosa che fa funzionare le cose normalmente è rimuovere i filtri dalla maschera.

Il problema si verifica indipendentemente dal sistema operativo in cui l'applicazione risiede (win 7, Win 10, ecc.)

Qualche suggerimento?

Grazie e ciao

[RobertoA]

Forse se descrivi meglio l'ambiente di lavoro, si potrebbe tentare di
capire cosa succede
Ad esempio 'utilizzando un filtro' prevede l'uso di una sola tabella o
piu' tabelle?
E queste, sul db, sono tra loro vincolate opure sono tutte slegate?
Dopo il mancato aggiornamento/eliminazione salta fuori qualche errore?
E come viene eseguito l'aggiornamento/eliminazione, nel senso mandi una
query passthrough al db o fai sempre tutto lato Access?

[@Alex]

Ciao Davide, ben risentito.
Non mi è chiaro come esegui le Query di aggiornamento/delete, se lato Server(con SP) o lato Client tramite DAO con Query Action..?
Riesci a verificare se, con il filtro inserito, sia presente o meno un RecordLocks lato server...?

Ciao
@Alex

[Davide La Mantia]

Ciao Roberto,
utilizzando un filtro vuol dire che nel comando DoCmd.OpenForm aggiungo il filtro: "IDDocumento='"& stDocumento &"'"
La maschera ha come origine dati la tabella documenti e basta, la cosa non cambia se uso una query con un INNER JOIN tra la tabella documenti e la tabella anagrafica
L'update che non va a buon fine quando la maschera è filtrata è questa:

CurrentDb.Execute "UPDATE DocumentiRighe SET Auto=true WHERE " & st, dbSeeChanges

l'istruzione và perfettamente a buon fine se la maschera non è filtrata.

Analogamente non è possibile eliminare o modificare i record della sottomaschera che ha come origine la sola tabella DocumentiRighe, mentre tutto funziona regolarmente quando la maschera principale non è filtrata.

Le tabelle sono collegate tra loro con update in cascata sul campo IDDocumento

L'errore dice:

Errore 3157
ODBC: operazione UPDATE non riuscita su tabella collegata 'DocumentiRighe'

Se provo a modificare un record nella sottomaschera, dopo 60 secondi (classico tempo di timeout) ottengo lo stesso errore spiegato in modo più specifico:

ODBC: operazione UPDATE non riuscita su tabella collegata 'DocumentiRighe'
[Microsoft][ODBC SQL Server Driver]Timeout query scaduto. (#0)

Identico risultato se provo ad utilizzare una query passtrough!

Ciao

[Davide La Mantia]

Ciao Alex,
ben ritrovato!
le query sono tutte DAO, ma anche provando una passtrough non cambia nulla.

Il tuo ultimo suggerimento mi sembra interessante, nel senso che con il filtro magari access invia un qualche blocco al db, ma devo verificare...

Ciao

[Davide La Mantia]

Novità,
dopo un molto prolungato lasso di tempo (oltre un'ora) che la maschera è aperta, anche la maschera filtrata consente l'operazione.

Questo mi fa pensare che la maschera, se filtrata, provoca un lock sul server (come suggeriva Alex)

Resta da capire perchè succede e come impedirlo...

Ciao

[@Alex]

A me pare che sia già stato affrotnato questo argomento diversi anni orsono... ma non ne trovo traccia...

Chiaramente il Filtro a te serve, e quando operi è valorizzato(Filter<>"" e FilterOn=True)...?

Hai provato a vedere se, fa differenza filtrando con Filter di Maschera e con Filter di Recordset...?

Il Rs neutro è:
Dim rs As DAO.Recordset
Dim rsFiltrato As DAO.Recordset
Set rs=DbEngine(0)(0),OpenRecordset("SELECT * FROM T1")
rs.Filter = "ID= " & ValoreID
Set rsFiltrato = rs.OpenRecordset
Set Me.Recordset=rsFiltrato

Prova a vedere se in questo modo il Blocco agisce nello stesso modo..., chiaramente è solo per capire non ho la soluzione.

Vedo se trovo quel 3D che sono certo di ricordare...

@Alex

[Davide La Mantia]

Anche io ho cercato, ma non ho ancora trovato nulla.
Il filtro è:
Filter="IDDocumento='001010'"
FilterOn=True

Tuttavia il problema si verifica anche aprendo la maschera da codice e facendogli cercare e selezionare il record di interesse sfruttando openargs per passare il numero di documento cercato.
Basta spostarsi avanti e indietro nei record della maschera principale perchè il problema scompaia e la update vada a buon fine senza intoppi.

Ho provato a impostare la tabella documenti come origine record, senza alcuna query, ma le cose non cambiano.

Non sono sicuro di aver capito il tuo suggerimento sul Rs neutro.

Ciao
Davide

[Davide La Mantia]

Il giorno martedì 21 settembre 2021 alle 14:13:46 UTC+2 @Alex ha scritto:

Ok,
su SQL Server la query:

SELECT object_name(resource_associated_entity_id),* FROM sys.dm_tran_locks

Mi dà l'elenco delle tabelle bloccate, tra cui quelle su cui la update interviene.

Sembra che Access, dopo aver caricato i dati nella form, si dimentichi per un po' di rilasciare i blocchi.
Che tu sappia, esiste una istruzione esplicita, otre al chiudere la maschera?

Ciao

[Simone Calligaris]

> Tuttavia il problema si verifica anche aprendo la maschera da codice e facendogli cercare e selezionare il record di interesse sfruttando openargs per passare il numero di documento cercato.

Nel senso che non funziona nemmeno con:

Me.RecordsetClone.FindFirst <TuoCritierioRicerca>
Me.Bookmark = Me.RecordsetClone.Bookmark

?

Saluti

[Davide La Mantia]

Esatto.
Il record viene regolarmente visualizzato nella maschera, ma è come se tutte le tabelle coinvolte nella visualizzazione rimanessero bloccate sul server, qualsiasi tentativo di modifica provoca un blocco di 60 secondi (tempo di timeout) e poi l'errore senza aggiornamento dei dati.
Basta muoversi avanti e indietro nei record della maschera perchè il problema si risolva.

Analogamente, ogni tentativo di modifica dei campi da codice (Me.QuestoDato=100) provoca un errore come se qualcun altro stesse modificando il record, ovviamente nessun altro è connesso al db durante le prove.

Ciao

[Davide La Mantia]

PS:
nessun campo bit ammette valori null, le tabelle sono dotate di campo timestamp.

Ciao

[Davide La Mantia]

Ultimissime:

La sottomaschera provoca un lock di tipo S con lifetime impostato su 1.

Questo lock resta finchè non clicco a casaccio su caselle di testo nella maschera.
Finchè il lock esiste, non posso fare niente, appena scompare la maschera rifunziona.

Il programma ha funzionato ininterrottamente per quasi un anno e solo ora ha cominciato a dare problemi.

I record nella tabella sono meno di 9000, il che non giustifica oltre minuti e minuti di caricamento...

Uff...

[Simone Calligaris]

> > Me.RecordsetClone.FindFirst <TuoCritierioRicerca>
> > Me.Bookmark = Me.RecordsetClone.Bookmark

> > Saluti
> Esatto.
> Il record viene regolarmente visualizzato nella maschera, ma è come se tutte le tabelle coinvolte nella visualizzazione rimanessero bloccate sul server, qualsiasi tentativo di modifica provoca un blocco di 60 secondi (tempo di timeout) e poi l'errore senza aggiornamento dei dati.
> Basta muoversi avanti e indietro nei record della maschera perchè il problema si risolva.
>
> Analogamente, ogni tentativo di modifica dei campi da codice (Me.QuestoDato=100) provoca un errore come se qualcun altro stesse modificando il record, ovviamente nessun altro è connesso al db durante le prove.

Mi sto chiedendo come mai non incontro problemi analoghi (misteri di Winsozz): l'inghippo si verifica anche da altri Clienti?

Comunque, prova ad aggirare facendo fare a programma ciò che fai a mano:

Me.RecordsetClone.FindFirst <TuoCritierioRicerca>
Me.Bookmark = Me.RecordsetClone.Bookmark

DoCmd.GoToRecord acDataForm,, acNext
DoCmd.GoToRecord acDataForm,, acPrevious

[Davide La Mantia]

Dopo aver provato di tutto, tra cui aggiunta di campi timestamp che dicevo, e verifiche varie ritengo di aver individuato il problema:
Una combo aveva come origine record una vista.
La vista in questione è è raggruppata e calcola la giacenza degli articoli.
Nonostante questa questa vista venga eseguita in 122 millesimi di secondo, quando questa vista era inclusa come rowsource della combo, eseguiva un lock di tipo S sulla tabella DocumentiRighe con request_lifetime impostato a 1, che mandava quindi in timeout qualunque aggiornamento della tabella, inoltre creava una serie di lock di tipo IS su altre tabelle.
Ho cambiato la rowsource della combo e il problema non si verifica più.

Resta da capire perchè prima non succedeva, dato che la cosa non è legata al tempo di esecuzione della query che, ripeto, viene eseguita in 122ms e restituisce appena 9000 record su tabelle dello stesso ordine di grandezza.

Ciao

[Simone Calligaris]

> Resta da capire perchè prima non succedeva, dato che la cosa non è legata al tempo di esecuzione della query che, ripeto, viene eseguita in 122ms e restituisce appena 9000 record su tabelle dello stesso ordine di >grandezza.

Come sempre in questi casi solo gli sviluppatori di MS potrebbero darci risposta, e magari dopo aver perso un paio di giornate a rincorrere la casistica.
Però sono sollevato dal fatto che tu abbia identificato un problema facilmente aggirabile (a parte il tempo che hai perso), potenzialmente preoccupante per tutti.

Saluti

[Davide La Mantia]

Ciao Simone,
sì, stava diventando un problema e mi preoccupava per il futuro, l'applicazione oltra a gestire magazzino, fatturazione e vendite, emette anche gli scontrini, quindi avevo un cliente in panne...
Il mistero maggiore è, come dicevo, perchè queste anomalie si presentano all'improvviso dopo vari mesi o addirittura anni di regolare funzionamento (e senza aumento significativo dei record)

Ciao

[RobertoA]

Come lo rilevi il lock tipo 5 e lifetime 1 ?