Newsgroup: it.comp.appl.access
Titolo: Query o sql

Salve  Mi date un consiglio in Msaccess ï¿œ meglio utilizzare le query o 
le istruzioni SQL quale delle due ï¿œ piï¿œ performante

 le istruzioni SQL quale delle due � pi� performante
Non c'� differenza tra il qbe e impartire le istruzioni sql selectt  from 
ecc.
Il QBE tritura un po' troppe parentesi.
Preferisco utilizzare l'sql pi� pulito e leggibile. Mentre il qbe pu� essere 
un inizio per comprendere meglio la sintassi.
Ci sono query complesse che il qbe non � in grado di visualizzare 
(specialmente le subquery con alias che puntualmente si corrompono in qbe)
In termini di prestazioni ovviamente non c'� differenza se lo statement 
prodotto � lo stesso
Ciao
Daniele 


Ti ringrazio, volevo eliminare molte qbe e tradurle in sql solo che se 
il risulto resta lo stesso, lascio perdere. Grazie di nuovo.
Approfitto della tua cortesia, tu sai come si possono creare le tebelle 
in un database collegato firebird tramite sql da access, ho creato un 
collegamento di rete perï¿œ ora dovrei trasferire le tabelle con i dati
sai qualcosa o anche qualche dispensa che puï¿œ aiutarmi ti ringrazio.

 ringrazio.
Con gli statement � sempre un'altra cosa ;-)
http://www.w3schools.com/Sql/sql_select_into.asp
dove vedi oldtable � la tua query pass-through invocata con connesione odbc
Ciao

OneEDP ha scritto:


Ciao Daniele, non voglio contraddirti ma in verit� il qbe � + performante, in
quanto le query hanno gi� il 'piano d'attacco' bell'e pronto!!!!
Per la manutenzione sicuramente sono pi� comode, anche se ovviamente hanno dei
limiti.....Io tendenzialmente utilizzo il codice puro per l'SQL ma non posso
negare che alcune cose siano mooooolto pi� performanti da qbe...per non
parlare poi del fatto che Access scherma tutto il casino con le conversioni, i
campi null, le date......che altrimenti devi fate tu a codice e, si sa,
l'omarino che pigia i bottoni ha + limiti del qbe.......almeno QUESTO omarino
qui.....
Ciao 
Roberto
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 Roberto
Ciao 

OneEDP ha scritto:



Per quanto riguarda union e sub-query nn mi trovi d'accordo....ma
D'ACCORDISSIMO!!!!!!!!!!!!!
Parlavo solo delle query 'normali'.....anche a me son capitate teratologie nel
qbe!!!!
Penso per� al fatto di scrivere, x es, una INSERT dove c'� una data, che nn �
obbligatoria......� necessario o un if o un iif x dirgli #data# uppure
null....il qbe fa lui, come nel caso di stringhe con l'apostrofo o di valori
testo/numerico/data nulli.....d codice devi tentare di controllare tutto, dal
qbe ci pensa Mr A......chiaro che i limiti ci sono.....query al volo, stringhe
WHERE multicampo....x nn parlare appunto delle union o sub.....
;)


 Roberto 


Ho visto che l'argomento interessa e sono contento che ci sia stato 
anche RobertoA, per me quello di cui parlate anche se poco conosciuto e 
tutto oro, in quanto come sï¿œ Roberto per me ormai ï¿œ l'unica strada da 
percorrere per lavorare in access in rete. Grazie a tutti e due dell'aiuto
Gianfranco


ho provato, ma credo che ho sbagliato in qualcosa oppure mi sono 
espresso male il file di destinazione collegato tramite server firebird 
ï¿œ del formato firebird. Ho provato ad eseguire alcune istruzione per 
creare una nuova tabella ma mi dice file non valido ï¿œ chiaro che il file 
non ï¿œ mdb ma ï¿œ Fdb. Puoi darmi qualche chiarimento in merito. Ti ringrazio
Questa ï¿œ la stringa:
SELECT Users.* INTO [+clienti] IN '23.255.113.19:d:\comune \PROVADATI.FDB'
FROM Users;
users ï¿œ la tabella in access +clienti dovrebbe essere la nuova tabella 
in fdb. Sicuramente ï¿œ un casino, ma questo ï¿œ quello che ho capito

 in fdb. Sicuramente � un casino, ma questo � quello che ho capito
Per collegarti al server crea un file txt vuoto e rinominalo con .udl e fai 
doppio click e prova a impostare i parametri per connetterti.
Domani vedr� di darti altre dritte
ciao
Daniele
Male che vada collegati odbc la tabella Clienti in scrittura e fai la 
inserte senza specificare il percorso

Gianfranco
Nn sono RobertoA!!!!! Lui ne sa moooolto pi� di me!!!! :) 
Omonimia........il nick � Fair87 ma se preferite mi identifico con
RobertoF!!!!!


 dell'aiuto Gianfranco
Ti segnalo questo link dove hai tutti gli strumenti 
http://msdn.microsoft.com/en-us/library/aa139932%28office.10%29.aspx
Ciao
Se riesco prova ad inviarti un esempio
Daniele 

>>>>>>
Buongiorno a tutti. Ho fatto alcune prove: allora, ho visto che per via 
odbc posso esportare le tabelle
completamente da access a firebird e ricollegarle, ho visto come su 
access si creano le query pass-through ed ho potuto lavorare sulle 
tabelle. Ora rimane solo un ostacolo il campo contatore, con 
l'esportazione il campo ï¿œ diventato un campo numerico ho visto che posso 
  farlo diventare autoincrementale partendo da un determinato numero ed 
ï¿œ ottimo perchï¿œ si recuperano tutti i campi ID contatore, ma ho provato 
a farlo e non si autoincrementa aggiungendo un nuovo record. Potete 
darmi qualche chiarimento?


Scusate altra domanda importante, le query che vengono fatte in access 
per mezzo delle tabelle collegate via ODBC creano un flusso dati sulla 
rete? Le query pass-through, permettono invece di effettuare delle query 
direttamente nel server. E' giusto? devo quindi convertire le query in 
query pass-through? grazie

query pass-through? grazie
No, non � esatto. SE la query 'locale' non contiene funzioni proprietarie
(Dcount, Dsum....), funzioni definite dall'utente, pivottamenti vari
(TRANSFORM) o modi proprietari di Access, � compito del driver ODBC passarle
direttamente al server, con risultante minor traffico di rete. La differenza
con un'applicazione client/server non � propriamente questa.....ma il
centralizzare OGNI operazione dei dati SUL server, per garantirne l'integrit�,
la correttezza, la velocit� e la manutenzione corretta. Questo � il vero BE e
FE.....pensa solo se in una INSERT (che fa cmq il server) dai client che
utilizzano per esempio la funzione Now() nello statement SQL.....se un client
si gira male e perde la data corretta (a me � successo...)??? Ecco che la
consistenza dei dati � gi� andata a pallino.....se la stessa cosa la fai con
una Stored Procedure, anche se il server sbaglia la data, la sbaglia per
tutti......E poi se cambi la stored, la cambi 1 volta sul server....i client
continuano ad invocarla senza manco sapere nulla....


 query in query pass-through? grazie
Le tabelle collegate sono una cosa diversa dalle query pass-through.
Io personalmente demonizzo le tabelle collegate, prova a verificare con un 
freeware netperse e ti renderai conto dell'enorme traffico di rete generato.
Con lq qpt ottieni solo ci� che richiedi e non l'intera tabella di milioni 
di record.
Purtroppo non si riesce a sfatare il mito delle tabelle collegate.
Prova a mettere in join due tabelle collegate e ti vedrai precipitare i 
milioni di record in locale, magari per un solo record.
Sono rari i casi in cui l'odbc � intelligente nelle tabelle collegate e non 
pui fidarti.
Indi sono per le qpt ;-)
Ciao
Daniele 


Qui si apre un dibattito su dove spostare la logica: sul server o sul 
client. :-)
Mi astengo per ora, in altri 3d i parereri sono stridenti.
Diciamo che sono server-centrista...
Ciao
Daniele 


Wait.....come nell'altro 3D diciamo che siamo 'prigionieri' di eccessi di
Access....� ovvio che se per tabelle collegate intedi provenienti da DB
diversi (anche mdb) � il client che deve sobbarcarsi tutta
l'elaborazione....noi le vediamo tutte nella zona tabelle, ma in verit� sono
da basi-dati diverse!!!! E qualcuno le deve mettere pur insieme.....se provi,
ad es, a fare un join eterogeneo tra una tab mdb (locale) e una tab su SQL
server vedrai che dolori!!!!!
Prima avevo la base dati sparsa in 2/3 mdb x questione di spazio. Poi upgrade
con ODBC. Ti dico la verit�: collegando TUTTE le tabelle che risiedono su SQL
al mio db Access nn ho avuto nessun problema di prestazioni manco sui massimi
storage di dati (lavoro con quasi un milione di record e nn so + manco io
quante join...), quindi deduco che, con dovuti accorgimenti, il driver ODBC
(almeno per l'ambiente access-SQL server) lavora molto bene insieme a jet, e
come 2 vecchi amiconi si spartiscono il lavoro al meglio (x ora...almeno....)


 amiconi si spartiscono il lavoro al meglio (x ora...almeno....)
E' evidente che i driver che ho hanno qualcosa che non va. 


A quanto pare ï¿œ una foresta e per uno come me che ha iniziato ad 
entrarci rischia di perdersi. Cmq se ho capito bene le query effettuate 
per mezzo delle tabelle collegate via odbc vengono eseguite dal server e 
quindi senza flusso dati eccetto le risultanze, mentre le query 
pass-through sono delle istruzioni dirette al server. Ad esempio se devo 
aggiornare le giacenze di magazzino e quindi scrivere nel campo giacenza 
del prodotto posso eseguirlo direttamente sul server, tipo:
giacenza=qta iniziale+ movimentiprodotto(carico e scarico), posso 
eseguire una somma del campo della tabella movimenti ed il risultato 
inserirlo nell'anagrafica prodotto del tipo:
calcolo totali per prodotto
"SELECT [Magazzino: Search segno su bolle].ID_MAGAZZINO AS id, 
Sum([Magazzino: Search segno su bolle].qta1) AS Tqta INTO [Temp: 
Aggiornamento giacenze]
FROM [Magazzino: Search segno su bolle]
GROUP BY [Magazzino: Search segno su bolle].ID_MAGAZZINO;"
assegnazione valore a sing prodotto
"SELECT [Magazzino: Search segno su bolle].ID_MAGAZZINO AS id, 
Sum([Magazzino: Search segno su bolle].qta1) AS Tqta INTO [Temp: 
Aggiornamento giacenze]
FROM [Magazzino: Search segno su bolle]
GROUP BY [Magazzino: Search segno su bolle].ID_MAGAZZINO;
queste due istruzioni lavorano ora con tabelle collegate access(MDB)
tempi molto alti via rete meno di un secondo locali
nel caso le tabelle sono su server sql firebird collegate  via ODBC 
l'elaborazione avviene nel server oppure funzionano come quelle mdb e 
quindi eseguire queste istruzioni tramite query pass-through?

 quindi eseguire queste istruzioni tramite query pass-through?
Non conosco firebird ma penso che quello che hai descritto sia l'sql di 
firebird.
Hai provato a creare una qpt un esempio 
http://support.microsoft.com/kb/303968/it
Un esempio
1) creare al volo una tabella locale (su mdb) dal server in modulo vba:
CurrentDB.Execute "SELECT * FROM MyQryPassThrough INTO tblLocale"
2) popolare una tabella locale (su mdb) dal server in modulo vba:
CurrentDB.Execute "INSERT INTO tblLocale SELECT * FROM MyQryPassThrough"
dove MyQryPassThrough � la tua nativa query firebird che ti pu� resituire 
uno, nessuno, centomila record
Ripeto i tempi delle tabelle linkate sono alti perch� Access deve rimestarsi 
tutta la tabella Magazzino
se crei la tua query pass-through come l'esempio riportato, i tempi 
dipendono esclusivamente dalla capacit� del provider dati e dalla rete.
Come fare a creare le qpt al volo?
Intanto l'oggetto CurrentDb.QueryDefs("myQueryPassThrough").SQL ti 
restituisce lo statement che per tua sorpresa � in lettura e... in 
scrittura.
Con F1 trovi le indicazioni.
Ma ovviamente se firebird consente viste parametrizzabili allora � molto 
meglio. Tutto dipende da firebird che strumenti mette a disposizione.
Conclusioni IMHO.
Abbandona le tabelle collegate.
Se non ti convince l'idea prova a monitorare la rete con netpersec 
(freeware)
Utilizza le query pass-through e riesci a trovare un modo per 
parametrizzarle, ti sembrer� di avere un altro server.
Attento a non fare come me come quando all'inizio senza conoscere ANSI-SQL 
aggiornai 16000 anagrafiche impostando lo stesso nome (mancava la where)... 
per fortuna c'era una copia in locale.
Vedrai che sar� molto pi� semplice ragionare direttamente in sql che con 
troppe acrobazie grafiche.
Ciao
Daniele 


Conrinuo ad esprimere la mia versione, nel rispetto di tutti
chiaramente......
Secondo MS Access lavora meglio in tabelle collegate piuttosto che aprire e
chiudere tabelle sul server. L'SQL, che sia on the fly o QBE, se fatto bene e
senza funzioni proprietarie lavora sul server MA NON E' come se lo facesse il
server......l'unica VERA maniera per un'applicazione client/server sono le
viste e le stored: alleggeriscono il client e garantiscono la congruenza dei
dati SEMPRE. Nell'esempio delle giacenze, la soluzione dovrebbe essere: ogni
volta che nelle righe di carico/scarico viene aggiunto/tolto qcosa, allora si
scatena un trigger che aggiorna la tabella giacenza. Il motore SQL fa le
operazioni INSIEME e non potr� mai succedere che si aggiorni una riga senza
che si aggiorni anche l'altra....
Per Daniele: quella della WHERE mancante.........quante volte mi �
successa!!!!!!!!
;)
Ciao 
RobertoF


 RobertoF
Ciao
Daniele 

Sei riuscito a recuperare in tempo?
Di filosofia mi sa che ne stiamo facendo ben poca!!!!!! ;)
Qua � tuta roba praticissima!
Cmq x la cronaca io nn sono un programmatore di professione, quindi prendi i
miei interventi con le pinze!
Il mio db lavora su quasi un milione di righe. Ogni riga � composte da 60
campi.....prima di sql server era tutto su mdb, e ti dico, con
moooooooooooooooolte alchimie in una Lan era + che dignitoso....Il passaggio a
ODBC l'ho fatto da non troppo (sempre lan) e su pc veryvery old (tranne il pc
server che � un pochino scafato) e mi son trovato molto bene (per ora). Sono
straconvinto che sia una pezza (T-SQL lo sto approfondendo adesso, anche se nn
credo riscriver� alcunch�....lo uso sui prossimi progetti: il mio applicativo
� troppo complicato e vasto da riscrivere!!!!! Nn ne ho il cuore...). In VPN
nn l'ho provato ancora quindi magari mi rimangio tutto...far� sapere. Per
quanto riguarda la WHERE.....MAI!!!!! Mi son sempre mangiato le
mani.......Santo backup.....
