Newsgroup: it.comp.appl.access
Titolo: Queries o stringhe SQL ?

Vorrei un consiglio di strategia dello sviluppo di una applicazione:
premesso che si possono creare query in quantità come oggetti e che queste
equivalgono a stringhe sql e dal punto di vista della semplice efficacia si
possono inserire sia le prime che le seconde come parametri o proprietà sia
nelle maschere nei report o nei recordset creati da codice
e premesso che mentre all'inizio usavo creare una quantità smisurata di
oggetti query e ultimamente preferisco usare le stringhe sql (create magari
con l'interfaccia grafica).
Secondo voi, e naturalmente mi rivolgo soprattutto a chi è uno sviluppatore
piuttosto esperto, è meglio usare le query oggetto o le stringhe sql ?
Capisco che la domanda può avere risposte diverse a seconda dei contesti ma
per esempio:
sono più veloci le query-oggetto o le stringhe sql ?
io ho pensato di creare le query durante la fase di sviluppo però di usare
solo le stringhe e quindi poter cancellare le query create
tra l'altro non avendo molta dimestichezza con l'sql mi accorgo che usando
le stringhe sto acquistando un po' di confidenza con lo stesso....
--
AleC
Per scrivermi in privato rimuovi le XXX  XXXaca...@XXXiname.com
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ...sii attento mentre parli, con le tue parole
  tu crei il mondo intorno a te
                                    detto navajo
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 [cut]
mi scuso per l'ignoranza. query-oggetto? stringhe sql? cosa intendi?
come fai a creare le query-oggetto?
-- 
Alessandro Cara

 come fai a creare le query-oggetto?
Una Query o una stringa SQL, concettualmente, sono la stessa cosa. Anzi, una
query è una stringa SQL, ma non è detto il contrario, perchè una stringa SQL
può essere molto di più.
Dal punto di vista di access, però, SQL e Query sono la stessa cosa.
L'oggetto Query, però è quello che trovi nella scheda "Query" della finestra
database e, da codice VB o VBA, può essere trattato appunto come oggetto,
con le sue proprietà e i suoi metodi.
Una stringa SQL, invece, può servire a tante cose, può essere usata compe
proprietà di un oggetto Query, di un Recordset, ma, alla fine, è solo una
stringa di testo :-)
Non ho seguito il thread, quindi non so in che contesto è stata fatta la
domanda, ma penso cmq di aver spiegato la differenza fra la due cose.

 Comitato per l'emancipazione della query
ROTFL!
-- 
Federico
--------------------------------------
Sito Comune di it.comp.appl.access
http://members.xoom.it/it_db_access
--------------------------------------
Tutte le richieste che mi arrivano
in privato, vengono cestinate.
--------------------------------------
Rimuovi paperino. per e-mail
--------------------------------------

 Comitato per l'emancipazione della query
Perche'
-- 
Alessandro Cara
-----
Comitato per la difesa della query oggetto (sara' freudiana?)

 domanda, ma penso cmq di aver spiegato la differenza fra la due cose.
Questo e' male!
Dai Andrea che se ci mettiamo l'impegno, visto che "Albertone" ;<)))))
in questo periodo e' piuttosto attento potremo fare in modo di
rirompergli una sua proprieta' (o e' un oggetto?)
-- 
Alessandro Cara

 rirompergli una sua proprieta' (o e' un oggetto?)
Non so di che parli, non ti capisco: sarà un altro thread che non ho
seguito.

sono più veloci le query-oggetto o le stringhe sql ?
Un oggetto permanente QueryDef, nelle aree di lavoro di Microsoft Jet, può essere
considerato un'istruzione SQL compilata. Se si esegue una query da un oggetto
permanente QueryDef, la query verrà eseguita più velocemente di quanto potrebbe
avvenire se si eseguisse l'equivalente istruzione SQL dal metodo OpenRecordset.
Ciò accade perché il modulo di gestione di database Microsoft Jet non deve
compilare la query prima di eseguirla.
Saluti
Paolo


Grazie per la risposta perché in effetti tutti avevano cominciato a parlare
di cose diverse dal problema che avevo posto postando l'origine del thread
Per quanto attiene alla velocità quindi conviene creare delle QueryDef
permanenti (oggetti nella sezione Query della finestra database, a scanso di
equivoci e ulteriori interminabili threads sulle definizioni :] ) che sono
già precompilate invece di istruzioni SQL da piazzare nei vari metodi nel
codice.
Però il problema che volevo porre è. diciamo, di politica generale...
Premesso che il problema non si pone per Form Tabelle Report  (si pone meno
perché anche quelli possono essere costruiti da codice) è buona politica
crerare Query permanenti magari in numero molto alto oppure basarsi
soprattutto sulle strighe sql e se invece bisogna di volta in volta prendere
un decisione in base al contesto qualei direttive seguire nel processo
decisionale ??????


 Alessandro Cara


Ponendo l'attenzione sulla semplicità di manutenzione, mi verrebbe da dire che è
meglio creare molti oggetti querydef, con o senza paramentri, se invece tengo
conto dall'elasticità che voglio dare all'applicazione forse conviene gestirle
da codice, ad esempio creare una query sulla base dei campi scelti, o criteri
impostati dall'utente in una maschera, anche se qui qualcuno potrebbe
consigliare di creare degli oggetti querydef temporanei e poi abbandonarli
quando hanno finito il loro lavoro.
Probabilmente conviene creare querydef quando si presume che le query siano
molto lunghe in esecuzione, così da aver maggiori vantaggi derivanti dalla
presunta maggiore velocità di esecuzione.
In ogni caso bisogna tenere conto che gli oggetti querydef sono oggetti dao che
lavorano su DBMS MSJet, per cui nel caso tu volessi fare un applicazione che in
un secondo momento non usi più MSJet forse conviene creare le query da codice,
in modo rendere il tutto  + esportabile.
ma... la discussione potrebbe essere lunga, proviamo ad aspettare altri pareri,
sempre che non si mettano a discutere il sesso degli angeli...  :-))
Saluti
Paolo