Newsgroup: it.comp.appl.access
Titolo: SQL - Pass-Through

Buonasera
Ho potuto apprezzare la velocità delle queries PT che però hanno la
"caratteristica" di ritornare recordsets non editabili. Se (come
sembra) questo è vero, quale è la tecnica migliore per leggere i dati
sfruttando il server potendoli modificare ?
Grazie
MArco

MarcoVR presented the following explanation :

Lavorando su un database (meglio se in terminal server) per il quale si 
abbiano i diritti necessari, lasciando perdere le query PT.
 
Bruno
 
 


Quella che descrivo è la realtà con cui devo confrontarmi. Nessuna alternativa !!! Tra l'altro lavoro con i diritti di amministratore di dominio. Quindi ripropongo la domanda : il metodo più performante per popolare una form leggendo/modificando dati da un db SQL ? Grazie


Scrivendo una Query interpretabile SERVER SIDE...!
Dubito che una Query SELECT STANDARD sia più veloce se eseguita come
Q_PT...!
Se scrivi:
SELECT * FROM T1 WHERE ID=1
 
questa verrà eseguita sempre e solo ServerSide che sia PT o
normale...!
 
Se invece scrivi:
SELECT * FROM T1 WHERE ID=Forms!NomeFoem!NomeCampoId
 
direi che è decisamente un problema..., questa query non verrà mai e
poi mai eseguita lato Server, ma il Server eseguirà
SELECT * FROM T1
in quanto non in grado di interpretare la WHERE, che verrà delegata a
JET in locale...
Risultato perrime performance... e quì un pò le Q_PT aiutano.
 
Le Q_PT si usano principalmente per eseguire SP lato server, o per
popolare REPORT in modo da non alterare i LookEdit in caso di
multisessione/Multiistanza ... se non espliciti il READONLY sempre.
 
Se vuoi esporre in modo tecnico il tuo caso specifico... qualche
considerazione aggiuntiva potrebbe chiarire lo scenario.
 
@Alex


Quello che dici a proposito della clausola where che non può essere
eseguita lato server fa crollare le mie convinzioni, che mi ero fatto
leggendo discussioni a proposito. Nel mio caso avendo dei fortissimi
rallentamenti gestendo una tabella di un db access di 300.000 records
a cui vengono continuamente aggiunte righe ed eseguite ricerche in
multiutenza, ho risolto un upsize a sql (2005 express) ed eseguendo
queries pt che prevedono join e diverse condizioni where. Soddisfatto
vorrei ora ottimizzare l'intera procedura gestionale. In pratica le
classiche maschere di i/o la cui origine dati è spesso piuttosto
complessa e di conseguenza poco performante con jet. Quindi sto
cercando di capire quale è. La maniera migliore per farle eseguire
completamente al server. Grazie


Esempio semplice che rende l'idea...
 
1° Caso non Risolto SERVER_SIDE
    "SELECT * FROM T1 WHERE ID=Forms!NomeForm!CampoId"
 
2° Caso Risolto ServerSide
    "SELECT * FROM T1 WHERE ID=" & Forms!NomeForm!CampoId
 
La differenza è lampante... la 1° passa al Server la Stringa che
richiede l'interpretazione di una scritta non comprensibile... [Forms!
NomeForm!CampoId] per SQL_SERVER non significa nulla...
La 2° risolve il riferimento in modo ESPLICITO, aggregando il valore
alla stringa, SQL_SERVER non deve interpretare ma risolvere.
 
Stessa cosa se si usano funzioni di aggregazione sui domini, che con
un Server SQL è meglio gestire con SubSELECT...
 
Ecc.ecc. ecc...
 
In generale tuttavia per non andare a caso, hai a disposizione il
QueryAnalizzer, quindi puoi intercettare in SQL_SERVER il predicato
inviato ed i piani di esecuzione ServerSide... serve un pò di
esperienza in quanto non c'è
moltissima documentazione, ma si riesce...
 
@Alex

 - Mostra testo citato -
 
Le queries che utilizzo rientrano certamente nel 2° caso.
Ciò è confermato dal fatto che funzionano senza che le tabelle siano
collegate.
Mi resta sempre il dubbio che le queries "semplici" siano performanti
come le PT.
Perchè le avrebbero messe ?
Inoltre ho fatto un esperimento
 
Dim Q As QueryDef
Dim R1 As Recordset
Dim R2 As Recordset
Set R1 = CurrentDb.OpenRecordset("MD")
While Not R1.EOF
 Set Q = CurrentDb.QueryDefs("Query1")
 Q.SQL = "SELECT dbo_Posta.Mittente, dbo_Posta.Destinatario FROM
dbo_Posta WHERE dbo_Posta.Mittente='" & R1("Mittente") & "' AND
dbo_Posta.Destinatario='" & R1("Destinatario") & "';"
 Q.ReturnsRecords = True
 Set R2 = Q.OpenRecordset()
 Set R2 = Nothing
 Set Q = Nothing
 R1.MoveNext
Wend
Set R1 = Nothing
 
La tabella "MD" contiene coppie di valori (60.000 coppie) che passo in
sequenza come parametro alla query.
Rilevando i tempi di inizio/fine esecuzione ottengo:
 
18,52 minuti se Query1 è "normale"
  5,26 minuti se Query1 è PT.
 
Sembrerebbe (e mi sto convincendo) che pe PT siano più performanti.
 
Quindi:
Se le "normali" non sono performanti;
Se le PT sono performanti ma ritornano recorsets non editabili
(problema iniziale);
Quale altro metodo (se esiste) conviene utilizzare ?

La reale differenza tra le 2 è che le PT non vengono precompilate da
JET, e la compilazione comprende la VALIDAZIONE della sintassi...
ovvio che implica ottimizzazione.
Le Q_PT possono essere scritte direttamente con un linguaggio T-
SQL(non supportato da JET)...
 
Puoi eseguire delle SP ServerSide... sai bene che le SP hanno una
complessità di elaborazione ed una ottimizzazione molto evoluta
rispetto allo script SQL(JET).
 
Leggi magari anche questo:
http://support.microsoft.com/kb/128808
 
 
e questo se vuoi fare qualche test più avanzato di quello che hai
fatto fino ad ora...
http://www.mssqltips.com/sqlservertip/2023/microsoft-access-pass-through-queries-to-sql-server-in-detail/
 
 
@Alex
 

 @Alex
 
Ho creato delle sp che aggiornano dati, ma non mi sembra utili per
popolare una form (meglio se continua). Sottolineo mi sembra. Mentre
approfondisco sarebbero molto utili degli esempi. Grazie.

     "SELECT * FROM T1 WHERE ID=" & Forms!NomeForm!CampoId
 
Non condivido affatto.
 
Entrambe le query vengono tradotte da Access in istruzioni SQL che il database collegato tramite ODBC possa elaborare.
Nel primo caso viene generata una query parametrica, nel secondo una semplice clausola where (come potrai vedere nell' SQL Server Profiler).
 
Le query passthrough invece non vengono tradotte da access ma vengono "sparate" al server così come sono, senza filtro, quindi in entrambi i casi si risparmia il tempo di traduzione della query da query access a query per il server.
 
Altra differenza sta nel fatto che nella query passthrough puoi inserire la sintassi del server e anche le funzioni e tutto il resto, che access non può tradurre mentre, viceversa, nelle query normali puoi inserire i riferimenti alle maschere e a tutti gli oggetti di access che non puoi inserire nelle query passthrough.
 
Ciao

Ciao Sib, ci sei ancora allora. ..
Si quello che dici è  corretto, non immediato da far capire, non avevo letto bene il tuo riferimento.
Sulle prime 2 da quanto ricordo il riferimento implicito al controllo forzata il server a restituire tutto il recordset e la where era in locale proprio jet ad applicarla, mentre la parametrica consentiva la restituzione del solo Rs soddisfacente. 
 
Il discorso, completo, si potrebbe fare se si facesse uso di ADP ma con Access, personalmente, direi che le qpt le uso solo per eseguire Sp.
 
Ciao mi fa piacere risentirti. 
@alex