Newsgroup: it.comp.appl.access
Titolo: Connessioni, Transazioni e Tabelle Collegate

Salve,
non potendo fare altrimenti, ho dovuto impiegare delle tabelle collegate per
un mio applicativo.
Le tabelle sono collegate a tre database diversi su RDBMS diversi ma quelle
che interessano la problematica sono collegate a tabelle su SQL Server 2000.
Fino a qui ....
Orbene, ho protetto una sequenza di operazioni di lettura (SELECT) e
scrittura (INSERT/UPDATE) con una transazione usando la libreria DAO.
La sequenza è la seguente:
BEGINT
for t=1 to N
    - LeggiTabella(A)
    - ScriviTabella(B)
    - ScriviTabella(A)
next t
COMMIT
con N costante.
Al terzo ciclo (N=3) si entra in DeadLock.
Guardando la lista delle connessioni di SQLServer 2000, eseguando la Stored
Procedure sp_who,  scopro che Access2000 apre due connessioni, diciamo c1 e
c2, e che la connessione c1 è bloccata dalla connessione c2. (Scusate se uso
il termine connessione come sinonimo di sessione).
Ciò mi fa pensare che:
Al ciclo N=2 c2 ha modificato la tabella A e il Lock Manager di SQL Server
ha, giustamente, attivato un lock esclusivo sulla tabella A.
Al ciclo N=3 lo STRONZO di Access, invece di usare la connessione c2 per
eseguire la lettura sulla tabella A, usa la connessione c1 e, giustamente,
il Lock Manager si incazza!
Dunque nasce il deadlock!
Per far funzionare il tutto o potrei togliere la transazione (cosa che farò
se non troviamo una soluzione più elegante) o potrei dire allo stronzone di
usare la stessa connessione per le operazioni sulla tabella A.
Come si può utilizzare una stessa connessione o, al limite, limitare le
connessioni di access verso SQL Server ad una sola quando si usano le
stramaledettissime tabelle collegate?
Grazie in anticipo per l'attenzione.
Saluti.
-- 
Simplex2
www.mdenittis.it
_______________

 Al ciclo t=3 lo STRONZO di Access, invece di ...
Grazie.
-- 
Simplex2
www.mdenittis.it
_______________

 ha scritto nel messaggio
news:dq5p7a$16r$1...@domitilla.aioe.org...

Ciao Simplex2,
si vede che lavori per un ente pubblico!  :-)   queste correzioni mi
ricordano tanto le modifiche alle leggi!!!  al comma 22.1 sostituire la
parola "a" con "b"
Bando alle ciance e veniamo al problema.
Io userei un approccio diverso...
Non le collegherei proprio e userei ADO, apro una connessione  faccio le mie
belle modifiche e chiudo la connessione.
Se  la cosa è possibile per la tua applicazione dovresti avere di sicuro
meno problemi, se vuoi ...entriamo in dettaglio!
Ciao
-- 
Cinzia
---------------------------------------
|  
http://www.riolab.org
  |
---------------------------------------

 Ciao
E' quello che di solito faccio quando ho un solo database (in generale io
aborrisco le tabelle collegate).
Purtroppo quando ho più database su RDBMS diversi (nella fattispecie due
RDBMS su Sybase 11 - piattaforma Linux- ed un RDBMS Ms SQLServer 2000) le
cose si complicano un po'.
Nella migliore delle ipotesi, se dei DB gestiti con Sybase mi interessano
solo delle tabelle di Lookup allora creo un pacchetto DTS, le replico su
SqlServer2000, schedulo il pacchetto DTS e lavoro su SQLServer con ADO.
Se le tabelle su Sybase, come nel mio caso, sono soggette a forti carichi
transazionali percui non è pensabile ricorrere alla schedulazione di
pacchetti DTS di importazione, allora o uso ADO  e implemento i JOIN da
codice VBA (il che significa fare un grosso sforzo computazionale per
ottenere scarse prestazioni), oppure uso il buon MS JET con le tabelle
collegate di Access.
Inoltre vi è il piccolissimo problema che il programma ha già qualche
migliaio di linee di codice ed è in produzione (almeno lo è la versione
precedente).
Se hai qualche idea fammelo sapere.
Possiamo certamente entrare in dettaglio.
Ciao.
-- 
Simplex2
www.mdenittis.it
_______________


Ciao Simplex,
certo che è una bella situazione incasinata...
potresti provare a collegare i db Sybase a SQL SerVer 2000 via Linked Server
ed  eseguire poi la transazione in una sp di SqlServer .... ma non ho
esperienza con Sybase x cui non saprei dirti se potrebbe funzionare.
Fai sapere...
Ciao
Cinzia

 Cinzia
Neanche io.
Se fosse per me lo butterei nel cesso.
Purtroppo, però ....
-- 
Simplex2
www.mdenittis.it
_______________

 che interessano la problematica sono collegate a tabelle su SQL Server
2000.
(cut)
Scusa Simplex ma le tabelle collegate, che a te piacciano o meno, sono
comodissime (e fanno ottimamente il loro dovere) per lettura e data entry
... ma non vedo una grande "necessità" in fase di batch sugli archivi.
Cioè, tra utilizzare codice DAO su tabelle collegate o Query PTh non ci sono
differenze significative in termini di tempi di sviluppo.
Mentre le differenze sono importanti in quanto a prestazioni.
Quindi, perchè nella casistica che hai esposto non ricorri a Query Pass Th o
ODBCDirect?
Ciao, Oscar

 ha scritto nel messaggio
news:43c79cfa$0$1077$4faf...@reader2.news.tin.it...

Ciao Oscar.
-
Usare ODBCDirect?
No, per gli stessi motivi per i quali non posso usare ADO (vedi la risposta
a Cinzia in questo setsso thread).
Devo necessariamente ricorrere a DAO per usare JET
(
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsentpro/h
tml/vecondataaccessusingodbcdirect.asp).
Ricorrere a query Pth?
Suggeriscimi un modo in cui ciclare N volte tre query Pth all'interno di una
transazione senza incappare nel problema che ho esposto.
Grazie per l'interessamento.
-- 
Simplex2
www.mdenittis.it
_______________

 transazione senza incappare nel problema che ho esposto.
Beh, a grandi linee (per semplicità nel ciclo ho inserito una sola query
Insert) una cosa del genere:
Dim wrk As Workspace, dbs As Database
Dim qdf As QueryDef
Dim Descrizione As String, i As Integer
On Error GoTo GestErr
Descrizione = "ARGGGHHHH "
Set wrk = DBEngine.Workspaces(0)
Set dbs = CurrentDb
wrk.BeginTrans
' Crea Query PT temporanea
Set qdf = dbs.CreateQueryDef("")
With qdf
.Connect = StrConnect 'Stringa connessione in var. globale
' non restituisce records
.ReturnsRecords = False
For i = 1 To 100
.sql = "INSERT INTO Gruppi (IDAzienda, CodGruppo, DesGruppo) Values ('01',
'2', '" & Descrizione & i & "');"
.Execute dbFailOnError
Next i
End With
wrk.CommitTrans
Uscita:
Set qdf = Nothing
Set dbs = Nothing
Set wrk = Nothing
Exit Function
GestErr:
wrk.Rollback
Resume Uscita
Anche se non sono certo d'aver capito il tuo problema: in particolar modo la
ragione che, in apparenza, renderebbe imprescindibile l'uso di tabelle
collegate.
Ciao, Oscar

 collegate.
Prova a fare una JOIN o una UNION o altre query che coinvolgono tabelle di
due RDBMS diversi.
Se fosse possibile eseguire i JOIN con i recordset come con le tabelle sarei
molto contento ed avrei risolto molti problemi.


 molto contento ed avrei risolto molti problemi.
Beh...      :-)
Ciao, Oscar

 tabelle su un unico Server SQL?
Questioni di portafoglio.
Il cosiddetto TCO.
Costa meno 'arrovellarsi' il cervello per far funzionare un collage di
sistemi pensati oltre dieci anni fa e non interoperabili (anzi, dovevano
essere chiusi l'uno all'altro'), che muovere tutta la macchina
amministrativa per provvedere all'ingegnerizzazione integrata dei sistemi
(il cosiddetto BPR - Business Processes Reengineering) .
I costi non sono solo esprimibili in termini monetari ma di risorse, tempi e
fermo attività.
Considera, comunque, che stiamo parlando di una realtà di tipo Enterprise
(con Access hi hi hi  :-D ).
Comunque qualcosa bolle in pentola. Forse c'è l'intenzione di fare un
progetto di integrazione.
Finalmente, perchè non ne posso più di questo sistema.


 (con Access hi hi hi  :-D ).
Se non m'avessi spiegato le motivazioni, io troverei ridicola la vostra
soluzione mista a livello Back-End!   ;-)
Lavoro in un ente ospedaliero, credo di sapere cosa sia una realtà
Enterprise, e posso dirti che Access come Front Editor NON fa una piega
accoppiato a MS SQL Server.
Accoppiata, d'altra parte, diffusa anche in software enterprise venduti a
livello pacchettizzato.
Ciao, Oscar


Ciao, Michele
-- 
Simplex2
www.mdenittis.it
_______________

 soluzioni migliori di Access-MS SQL Server.
Se ci riferiamo a un utilizzo "ordinario" (un solo Server SQL), non è così
scontato:
Microsoft investe molto sia sul Server (vedi ver. 2005) che sui
clients (non solo .NET ma anche Access 12 sono in forte evoluzione).
E' vero che stiamo parlando di una società che ha una visione del software
più vicina al videogioco che al prodotto mission-critical (!), però...
:-)
Se invece per settore "un pò particolare" intendi la connettività a fonti
eterogenee, non sono in grado di fornire un'opinione circostanziata (per
lavoro mica sviluppo drivers ODBC o DB-RAD :-).
Comunque, dubito esistano soluzioni performanti al problema della
connettività tra fonti diverse: è una problematica molto complessa.
Ciao, Oscar