DLookup e suo dominio
Valerio Valentini
salvata, e da quello che ho potuto vedere deve essere salvata nel db in cui
uso la funzione. Io devo controllare se esiste un record in una tabella con
circa 5000 record in un'altro db sul server in rete, mi vengono in mente tre
soluzioni:
A)
collego la tabella e faccio il DLookup. Carica la rete?
B)
salvo una query locale sulla tabella dell'altro db e sulla query eseguo il
mio DLookup. Mi viene un dubbio, se non ho letto male non posso passare
parametri alla query, parametro che tra l'altro sarebbe una variabile,
quindi la query si carica tutti i record? Carica la rete?
C)
scrivo una query di accodamento in VBA a cui passo il paramentro della mia
variabile per accodare l'eventuale record, se esiste, ad una tabella locale
e poi o eseguo DLookup sulla tabella locale o controllo se contiene un
record ed alla fine eventualmente cancello il record.
Quale secondo voi risulta la soluzione migliore?
Ciao Valerio.
namor
Sono tutte uguali perchè access non è client/server, quindi in ogni caso
si carica dal db in rete l'intera tabella per eseguire le query in locale.
Il carico di rete dipende dalla velocità della rete, dalle dimensioni
della tabella e dalla frequenza con cui esegui le query.
Namor
--
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
desio
"namor" <do...@spam.me> ha scritto nel messaggio
news:cbr209$3dk$1...@news.newsland.it...
ma non ne sono sicuro
Antonio Biso
Uhmmm...
Ma tra i "pregi" esaltati da microsoft per A2000 non c'era proprio quello
che sulla rete avrebbe viaggiato solo il risultato della query?
Antonio
namor
Sinceramente non lo so, se c'era mi è sfuggito. Sarebbe una bella cosa.
Hai qualche riferimento, qualche articolo, che gli dò un'occhiata?
sv
> Ciao Valerio.
Questo articolo ti potrebbe interessare:
http://support.microsoft.com/default.aspx?scid=kb;it;209126&Product=accIN2
--
rgrds
SC
--
sv
> Antonio Biso ha scritto:
Suggerivo a Valerio questo articolo:
http://support.microsoft.com/default.aspx?scid=kb;it;209126&Product=accIN2
--
rgrds
SC
--
questo articolo e` stato inviato via web dal servizio gratuito
namor
> > > Uhmmm...
> > > Ma tra i "pregi" esaltati da microsoft per A2000 non c'era proprio quello
> > > che sulla rete avrebbe viaggiato solo il risultato della query?
> > > Antonio
> > Sinceramente non lo so, se c'era mi è sfuggito. Sarebbe una bella cosa.
> > Hai qualche riferimento, qualche articolo, che gli dò un'occhiata?
> > Namor
> Suggerivo a Valerio questo articolo:
> http://support.microsoft.com/default.aspx?scid=kb;it;209126&Product=accIN2
> --
> rgrds
> SC
Lì non parla esplicitamente di come vengono trasferiti i dati in caso di
db con tabelle collegate.
Qui invece
http://office.microsoft.com/assistance/preview.aspx?AssetID=HP051874531033&CTT=8&Origin=EC011081751033
ho trovato dei vaghi cenni, e comunque questo articolo si riferisce ad
access 2003, non al 2000:
- Use filters or queries to limit the number of records that you view in a
form or datasheet. This way, Access can transfer less data over the
network.
- In queries that involve linked tables, avoid using functions in query
criteria. In particular, avoid using domain aggregate functions (domain
aggregate function: A function, such as DAvg or DMax, that is used to
calculate statistics over a set of records (a domain).), such as Dsum,
anywhere in your queries. When you use a domain aggregate function, Access
retrieves all of the data in the linked table to execute the query.
Anche se non c'è scritto esplicitamente si potrebbe dedurre che
effettivamente vengano trasferiti solo i record necessari, anche se non
vedo come ciò sia possibile. Un mdb condiviso in rete potrebbe stare su un
PC che non ha Access e Jet in esecuzione, quindi chi è che seleziona i
record da trasferire? Non è possibile trasferire solo i record risultanti
dalla query se sul PC che ospita il BE non c'è un servizio che esegue la
query. Se l'esecuzione è affidata al Jet del FE locale non è possibile
eseguire la query senza trasferire tutti i dati di tutte le tabelle
collegate coinvolte. Forse che da Office 2000 o dal 2003 in poi viene
installato un servizio di sistema che si comporta da database server per
gli mdb?
Namor
--
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito
Valerio Valentini
"sv" <salv...@nospbox.enel.it> ha scritto nel messaggio
news:cbr9o5$873$1...@news.newsland.it...
Soluzione D) passo a SQL SERVER? :)
scherzi a parte cosa pensate di una soluzione ibrida, sempre che sia
possibile, di sviluppare in SQL Server solo la parte di tabelle molto grosse
a cui devo accedere molto spesso?
Mi risolverebbe molte cose? Riesco a far viaggiare in rete solo i dati che
di volta in volta mi servono?
Ciao Valerio.
namor
Se hai un buon server e accedi ai dati con query pass-through che vengono
eseguite sul server e restituiscono solo i record risultanti e nulla più
dovresti notare dei miglioramenti, ma a questo punto ti converrebbe
passare tutto il db su SQL Server e ottimizzare dove possibile.
Se lasci i dati un po' su access e un po' su SQL Server perdi la
possibilità di impostare relazioni con integrità referenziale, il che puo
rallentare le prestazioni e portare a dati inconsistenti.
Scegli una soluzione o l'altra, lascia stare l'ibrido a meno che la
tabellona che devi velocizzare non sia slegata dalle altre, nel qual caso
la puoi mettere su SQL Server.
Namor
--
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito
MA
"Valerio Valentini" <ijv...@tin.it> ha scritto nel
messaggio
news:rTaEc.548146$rM4.22...@news4.tin.it...
Guardati le query pass through
MAssimiliano
Valerio Valentini
"namor" <do...@spam.me> ha scritto nel messaggio
news:cbrf5c$2dq$1...@news.newsland.it...
> Valerio Valentini ha scritto:
>
>
> Se hai un buon server e accedi ai dati con query pass-through che vengono
> eseguite sul server e restituiscono solo i record risultanti e nulla più
> dovresti notare dei miglioramenti, ma a questo punto ti converrebbe
> passare tutto il db su SQL Server e ottimizzare dove possibile.
> Se lasci i dati un po' su access e un po' su SQL Server perdi la
> possibilità di impostare relazioni con integrità referenziale, il che puo
> rallentare le prestazioni e portare a dati inconsistenti.
> Scegli una soluzione o l'altra, lascia stare l'ibrido a meno che la
> tabellona che devi velocizzare non sia slegata dalle altre, nel qual caso
> la puoi mettere su SQL Server.
> Namor
>
>
L'idea era proprio questa, SQL Server per la parte di tabelle grosse e molto
movimentate e loro collegate, lasciare come tabelle normali quelle per così
dire di servizio.
Intanto che cerco sull'help cosa sono query pass-throug?
Riesco a scriverle da VBA, mi capita spesso di usare query volanti per
passargli delle variabili?
Ciao Valerio.
Antonio Biso
> Antonio Biso ha scritto:
>
> > Uhmmm...
> > Ma tra i "pregi" esaltati da microsoft per A2000 non c'era proprio
quello
> > che sulla rete avrebbe viaggiato solo il risultato della query?
> > Antonio
>
> Sinceramente non lo so, se c'era mi è sfuggito. Sarebbe una bella cosa.
> Hai qualche riferimento, qualche articolo, che gli dò un'occhiata?
> Namor
Sicuramente qui ci può aiutare l'esperto Karl.
Karl, ci rispondi???
Antonio
Valerio Valentini
"MA" <mas...@massimilianoamendola.it> ha scritto nel messaggio
news:0ubEc.10680$%l2....@news.edisontel.com...
>
> >
> > Soluzione D) passo a SQL SERVER? :)
> >
> > scherzi a parte cosa pensate di una soluzione
> ibrida, sempre che sia
> > possibile, di sviluppare in SQL Server solo la
> parte di tabelle molto grosse
> > a cui devo accedere molto spesso?
> >
> > Mi risolverebbe molte cose? Riesco a far
> viaggiare in rete solo i dati che
> > di volta in volta mi servono?
> >
> > Ciao Valerio.
>
>
> Guardati le query pass through
> MAssimiliano
>
Per il poco che c'è scritto nell'help, ridotto dalla mia capacità di
comprensione, sono query normali che passano da ODBC, che quasi non so
nemmeno cosa sia. Ora la domanda diventa: se mi studio ODBC per fare le
query pass-through, ha ancora senso trasformare il database in SQL Server o
tanto vale che lasci il database così?
Ciao Valerio.
namor
Access lavora in modalità file server (salvo smentite documentate), cioè
se fai una query su tabelle collegate recupera tutti i dati di tutte le
tabelle e poi esegue la query e ti dà i risultati.
Le query pass through le usi per dialogare con un server SQL, quindi in
architettura client-server. Praticamente invece che chiedere al server le
tabelle intere ed estrarsi i record, si manda al server direttamente la
stringa SQL. Il server la esegue e rimanda indietro solo i record
risultanti dall'SQL.
Supponi di avere in rete una tabella con 10.000 record ed una chiave
primaria, e di volere eseguire un SELECT * FROM tabella WHERE ID=5.
Nel primo caso access prende dalla rete tutti i 10.000 record e poi si
cerca quello con ID=5.
Nel secondo caso si spedisce al server SQL la richiesta "SELECT * FROM
tabella WHERE ID=5", il server la esegue e ti restituisce il risultato. In
questo caso in rete transita un solo record invece dei 10.000.
E' da considerare anche il fatto che solitamente i server sono più veloci
e performanti dei client, il che aumenta ulteriormente la velocità di
esecuzione delle query.
MA
"Valerio Valentini" <ijv...@tin.it> ha scritto nel
messaggio
news:5TbEc.548683$rM4.22...@news4.tin.it...
La differenza è fondamentale.
Le query PT vengono elaborate sul server non sul
client.
Ora se tu da una tabella di 10000 record magari in
join con un'altra, vuoi estrarre 100 record
piuttosto che 1 solo
un conto è tirarti su fino al client tutte le
tabelle interessate, per poi elaborarle in locale
ed infine restituire il risultato,
un altro è far fare tutto sto papocchio
direttamente sul server (quindi lui ha le in
locale) e ti invia via rete (anche se in odbc)
solo il record interessato.
MAssimiliano
Valerio Valentini
Scusa se interrompo questo tread, ma tu e MAssimiliano state rispondendo
alla stessa cosa. Quindi se puoi e vuoi continuiamo il tread sull'ultima
risposta di MAssimiliano e mio replay per non creare un doppione.
Spero si usi fare così :)
Ciao e grazie Valerio.
Valerio Valentini
Rispondo all'ultimo per semplicità visto che stiamo procedendo di pari
passo, scusa namor.
Perdonatemi, ma la teoria più o meno l'avevo anche capita, ciò che mi manca
è l'applicazione pratica.
str_Conn = "driver={SQL Server};" & _
"server=VVALEO;uid=;pwd=;database=Dati_Mag_SQL"
Set conn_dati = New ADODB.Connection
conn_dati.Open str_Conn
Set rst_Acqt = New ADODB.Recordset
Quella che ho incollato è una connessione ADO e non ODBC ad un SQL Server
suppongo, la domanda è farò una cosa simile?
e soprattutto posso scrivere in VBA cose tipo
strSQL = "SELECT miaTabella.mioCampo FROM suaTabella.suoCampo IN
daQalcheParte WHERE suaTabella.altroCampo = '" & strCheCerco & "'"
Set rst = db.OpenRecordset(strSQL)
oppure
INSERT INTO suaTabella.suoCampo IN daQalcheParte FROM " & strCheScrivo & "
AS strValoreNuovo;
Grazie per ogni aiuto
Ciao Valerio.
Valerio Valentini
mancavano le ultime virgolette, scusate.
Ciao Valerio.
Valerio Valentini
SQL Server è stato progettato inizialmente come un database client/server,
nel quale i dati e gli indici risiedono su un solo server al quale in molti
casi accedono più client della rete. Il traffico di rete viene ridotto
elaborando le query di database sul server prima di inviare i risultati al
client. In questo modo, l'applicazione client/server può eseguire le
elaborazioni nella posizione migliore, ovvero sul server.
Deve farmi pensare che se lo trasformo in SQL Server anche le query normali
vengono elaborate sul server e passano solo i dati che ho chiesto?
Ciao Valerio.
Karl Donaubauer
> "namor" <do...@spam.me> ha scritto:
>>> Ma tra i "pregi" esaltati da microsoft per A2000 non c'era proprio
>>> quello che sulla rete avrebbe viaggiato solo il risultato della
>>> query?
>>
>> cosa. Hai qualche riferimento, qualche articolo, che gli dò
>> un'occhiata?
>
> Karl, ci rispondi???
Non credo che posso aiutare molto qui perché la maggior
parte di questo che fa JET quando carica dati sulla rete
non è documentata ma segreto di MS.
Certo Access/JET è un sistema file server e esegua le query
in locale. Ma non è vero che per questo sempre carica tutta
la tabella sulla rete. I processi sono più complicati e ottimizzati.
In breve come la capisco io:
La query engine (sul workstation) prima chiede informazioni
sulle tabelle dal mdb sul server e carica le tabelle dei indici
usati. Con questa informazione carica parti delle tabelle che
sono necessario per mostrare e procedere sul workstation.
Poi p.e. quando si fa un MoveLast o un scroll, più record
necessario per l'azione vengono caricati - sembra che
non solo direttamente dalla memoria del workstation ma
anche sulla rete.
Non sono metodi fidabili come con un sistema C/S che
esegue la query sul server e sempre solo carica il risultato
sulla rete.
Invece ci sono metodi/trucchi che usano indici, pointer,
caching nel RAM ecc. La cosa la più importante in questa
connessione sono indici. Ma ci sono altri metodi all interno
che nessuno sa fuori di MS.
Vedi cosa dice michka che lavora per MS:
http://groups.google.com/groups?&threadm=uPKGxo4X%24GA.266%40cpmsnbbsa04
e le prove che ha fatto John Viescas:
http://groups.google.com/groups?&threadm=%23uRgX6NuDHA.2508%40TK2MSFTNGP12.phx.gbl
--
HTH
Karl
*********
Access-FAQ (tedesco): http://www.donkarl.com
fidirico
"Antonio Biso" <ch...@etruria.net> ha scritto nel messaggio
news:vFbEc.25168$GQ3.6...@twister2.libero.it...
Un paio d'anni fa c'è stato un bel thread sull'argomento:
http://makeashorterlink.com/?J14621EA8
Ciao
Galliano.
Karl Donaubauer
> Antonio Biso wrote:
>>>> Ma tra i "pregi" esaltati da microsoft per A2000 non c'era proprio
>>>> quello che sulla rete avrebbe viaggiato solo il risultato della query?
Certo ho parlato di JET e due file MDB. Invece tu forse qui intendi
SQL Server/MSDE come backend e un ADP di Access come frontend.
Questa è una architettura client/server dove certo solo vengono
caricati i risultati sulla rete. È una storia complettamente diversa
che è possibile nelle versioni >=A00. Ma la grande maggioranza
della gente che usa Access naturalmente usa JET e MDB.
--
cu