Newsgroup: it.comp.appl.access
Titolo: Tabelle ODBC Collegate

Ho un database Front end in access con delle tabelle collegata a SQL
Server Express 2005.
Utilizzo il login di SQL per leggere/modificare i dati.
Nella prima maschera del database chiedo all'utente di inserire nome
utente e password di SQL e quindi faccio il refresh delle stringhe di
connessione ODBC.
Riscontro la seguente anomalia e non riesco a capire dove sbaglio.
Quando nella maschera di login inserisco un nome diverso dall'ultimo
che ha effettuato il login, la procedura di riconnessione delle
tabelle funziona ma le tabelle restano collegate con le credenziali
dell'ultimo utente che ha utilizzato il Front end
Se chiudo il Front end lo riapro e rifaccio login con le credenziali
del nuovo utente a questo punto la stringa di connessione cambia e
tutto funzione correttamente.
Ovviamente vorrei che già al primo login cambiasse la stringa di
connessione.
Grazie.
Fabio.

 Fabio. 

 di letture per una manciata di record.
che alternative ci sono? 
come funziona una query pass-thru?


Non potrei dire, per il momento, del 3d che ti  ho indicato
Cmq con la qpt richiedi solo e soltanto quello che ti serve dal server nel 
linguaggio sql NATIVO del server
Ciao

 che alternative ci sono?
Normalmente le tabelle collegate vanno benissimo: vai tranquillo (almeno in 
LAN).
Ciao... 


Il fatto che i risultati siano veloci non vuol dire che sia il meglio.
IMHO ho constatato sia con SQL Profiler sia con altri DB che il traffico 
generato � veramente alto.
Prova a fare una rimanenza di magazzino di 890.000 record che restituiscono 
300 righe aggregate da mettere in join con l'anagrafica articoli e vedrai 
che risultati.
Prova a dare uno sguardo con lo freeware netpersec e ti accorgi che 
oggettivamente � ingente il trhrotput.
Anche collegando un altro jet, le cose vanno solo un po' meglio, perch� per 
mettere in join due tabelle locali hai come minimo bisogno di scandire le 
key.
Come gisutamente sottolinii almeno il lan... se poi devi confrontarti con 
una VPN preparati al linciaggio degli utenti :-)
Ciao
Daniele 

 una VPN preparati al linciaggio degli utenti :-)
E' una sottolineatura importante, perch� l'utilizzo di applicazioni in VPN � 
raro.
Almeno rispetto a LAN ordinarie e Terminal Server.
Ciao: Max 

 in VPN � raro.
Ditte che hanno filiali in vpn, non mi sebra cos� raro ;.)


(ti parlo di sql server)
Scusa ma ... ODBC, quantomeno con SQL Server, non funziona come dici.
Pu� accadere che venga effettuato un TableScan totale, ma solo in 
circostanze particolari.
Normalmente le istruzioni SQL vengono delegate al Server.
Questo tutorial in italiano riflette con precisione i comportamenti delle 
queries ODBC
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=281
Non � solo 'teoria':  basta analizzare i pacchetti (ci sono mille utility 
per farlo) inviati e ricevuti attraverso la rete da un applicativo per 
verificare il funzionamento.
E comunque � il funzionamento che ho sempre rilevato concretamente, da me e 
dalla clientela.
Ciao: Max

 Ciao: Max 

 basta poco, anche una virgola... o un punto e virgola, un'apice
No, io parlo specificamente di query ODBC basate su tabelle collegate (non 
che abbia nulla contro il Pass-Th, che a volte ho dovuto usare).
Su quella documentazione (che poi � una traduzione di fonti reperibili sulla 
KB microsoft) le pagine sull'argomento sono 16-19.
Ciao: Max


Ciao Max,
questo scambio � salutare, perch� scartavo a priori il Jet perch� lo 
ritenevo poco capace di discernimento, senza considerare gli altri limiti.
Ad aggravare la situazione nel mio contesto � che con i driver odbc db2 le 
cose sono addirittura improponibili.
Ma venedo a sql. Ho rivisto nuovamente attenzione � voluto nuovamente 
sindacare con il profiler.
Una query di tabelle collegate odbc del tipo
"
SELECT Sales_Orders.*, Sales_Orders.orderid
FROM Sales_Orders
WHERE (((Sales_Orders.orderid)<=10386))
ORDER BY Sales_Orders.orderid;
"
Genera in sql questo:
"
SELECT "Sales"."Orders"."orderid" FROM "Sales"."Orders" WHERE ("orderid" <= 
10386 ) ORDER BY "Sales"."Orders"."orderid"
"
14 letture
come vedi non c'� table scan perch� le api hanno fatto il loro dovere e si 
sono digerite a vicenda.
poi
"
declare @p1 int
set @p1=4
exec sp_prepexec @p1 output,N'@P1 int,@P2 int,@P3 int,@P4 int,@P5 int,@P6 
int,@P7 int,@P8 int,@P9 int,@P10 int',N'SELECT 
"orderid","custid","empid","orderdate","requireddate","shippeddate","shipperid","freight","shipname","shipaddress","shipcity","shipregion","shippostalcode","shipcountry" 
FROM "Sales"."Orders"  WHERE "orderid" = @P1 OR "orderid" = @P2 OR "orderid" 
= @P3 OR "orderid" = @P4 OR "orderid" = @P5 OR "orderid" = @P6 OR "orderid" 
= @P7 OR "orderid" = @P8 OR "orderid" = @P9 OR "orderid" = 
@P10',10248,10249,10250,10251,10252,10253,10254,10255,10256,10257
select @p1
"
20 letture
poi
"
exec sp_execute 
4,10258,10259,10260,10261,10262,10263,10264,10265,10266,10267
"
20 letture
fino a terminare lo scroll dei complessivi 140 record
per un totale di 350 letture
L'alternativa pass-through
"
SELECT *
FROM Sales.Orders
WHERE orderid<=10386
ORDER BY Sales.orderid
"
produce lo stesso statement in profiler e al termine dello scroll solo da 6 
a 10 letture logiche
OrderID � indice clustered ordinato.
 Non so. Non prendere a male questa mia analisi, ormai avrai compreso che 
siamo nello spirito di arricchire le nostre conoscenze-esperienze a vicenda 
e valurare sempre se nelle nostre metodologia si pu� migliorare qualcosa.
Aspetto un tuo feedback
Grazie.
Ciao
Daniele 

 vadano benissimo   :-)
Fiuti giusto e le uso in rete locale, ma benissimo non vanno, e non parlo 
neanche di velocita'.
Parlo di query identiche che, sulle medesime tabelle oracle accedute (? 
accessionate? accesse?) mediante login diverse, fungono o no a seconda 
del login (dello schema). 
Esempio: tabella A join AB join B. Clausola where su tre campi: data, 
logico e un campo codice numerico. La query ha sempre funzionato finche' 
mi hanno dato una diversa login. Da quel momento la query fallisce sempre 
per colpa del confronto sul codice numerico (se lo tolgo la query 
funziona, ovviamente poi occorrera' un secondo passo per selezionare il 
codice). "ODBC failed" senza codici ne' perche'. 
ALtri casi: una medesima query, sulle stesse tabelle, con le stesse join 
e gli stessi criteri, che su una applicazione e' velocissima e sull'altra 
e' lenta. Duplico la query razzo su una applicazione identica, a meno di 
un diverso codice prodotto: si intazza.
E non parlo di quando una query ha problemi di runtime, per una settimana 
funziona al primo colpo, la settimana dopo occorrono due o tre tentativi.
 
In definitiva un approccio facile e comodo, ma di cui non capisco mai 
cosa sta succedendo sotto. In quanto utente mi interessa il risultato, ma 
non mi sento mai in comando della situazione. 
Il caso piu' comune e' la query complessa su 4-5 tabelle che fallisce e 
che va sostituita da 2-3 query piu' semplici in sequenza, con tabelle 
d'appoggio intermedie. Un modo di fare che mi gonfia l'applicazione.

 del login (dello schema).
(cut)
Non conosco Oracle, e non ho idea se l'interfacciamento ODBC da Access 
funzioni a dovere.
In vita mia ho sempre utilizzato linked tables ODBC solo con MS SQL Server 
(varie versioni) senza riscontrare problemi del genere.
Purtroppo non posso esserti d'aiuto...
Ciao, Max

 sindacare con il profiler.
(cut)
Allora, faccio fatica a entrare nello specifico perch� non ho mai utilizzato 
il Profiler per testare queries ed applicazioni ODBC.
Pi� empiricamente, ma efficacemente, ho sempre fatto ricorso a utilities per 
mappare il traffico di rete. E quindi, vedere in termini di pacchetti 
inviati attraverso la rete la differenza tra una query scritta in un modo 
piuttosto che un altro.
Oppure queries ODBC su linked tables  vs.  Pass-Th, e cos� via (per la 
cronaca, dai test fatti nel corso del tempo non rilevo differenze 
significative nell'invio di pacchetti in rete tra una query ODBC supportata 
dal Driver e l'equivalente Pass-Th).
E' un metodo che mi ha permesso di creare gestioni utilizzate con profitto 
in aziende che lavorano con buone multiutenze (comunque non pi� di venti PC 
concorrenti).
Per questo mi permetto di scrivere "tranquillo, vanno benissimo", perch� so 
bene che pochi in questo ng. incontreranno realt� molto impegnative, diciamo 
da ente pubblico.
Evidentemente la situazione in cui lavori � pi� complessa, prevede pi� 
Client, oppure un misto tra LAN e VPN, e quindi nel corso del tempo hai 
maturato un know how in materia, davvero invidiabile.
Leggendo i tuoi thread si rimane colpiti dal livello d'approfondimento con 
cui hai indagato su molti dettagli.
Per�, hai il difetto d'essere assolutista: dai per scontato, sbagliando, che 
la realt� in cui operi sia la stessa di tutti gli altri  ;-)
A proposito, mi piacerebbe che tu esponessi i dettagli (quanti Client? 
quanti in VPN?, etc.)
Dal canto mio, ho sempre considerato SQL Server solo un mezzo per risolvere 
problemi che mi affliggevano con gli .mdb (grossi volumi di dati in primis) 
e che ho usato in maniera discretamente rozza. Ma, come dicevo, efficace.
Ciao: Max

 Ciao: Max
Ciao a te Max
E grazie del feedback!
Daniele 


Ho un problema analgo con il DB2 a causa di schifosi tracciati record in 
cui ad esempio dati numerici contengono spazi (nel migliore dei casi) o 
vecchi dati dovuti a copia e incolla in RPG!
Nel tuo caso i parametri di connessione possono essere concausa.
Solo una ipotesi: la lingua
In un client ebbi la felice idea di impostare diversamente la lingua e 
la stessa query come dici tu nuovo termine ;.) si intazzava!
Ciao
Daniele

 E grazie del feedback!
Ma sono io a ringraziare te: continua a postare su icaa, c'è solo da 
imparare (hai sostituito degnamente il grande Giorgio Rancati, purtroppo 
latitante)
;-)
Ciao: Max


Giorgio è il grande Giorgio, di mio anch'io a volte latito.  ;-)
Daniele