Newsgroup: it.comp.appl.access
Titolo: Access+SQL Server: quanto migliorano le prestazioni?

Buonasera tutti.
Sono in un momento particolare, ovvero: ho un database in forte crescita
come numero di record e come numero di utenti che lo utilizzano...
Prima di imboccare strade che non conosco, se vi dico che ho un db che ha
tabelle di cui la più grande contiene 40.000 righe, fatto cento, anche un pò
a spanne, installando SQL Server su un server XEON con 1 GB di ram che
utilizziamo con terminali in modalità desktop remoto, di quanto posso
migliorare le prestazioni?
Immagino che partiamo da una base (la mia...)di conoscenze un pò ridotte, ma
se mi potreste daer qualche indicazioni di massima, per me - e lo potete
immaginare- sarebbe già qualche cosa...
Ringrazio anticipatamente tutti quelli che mi daranno un aiuto, e ovviamente
rimango a vs disposizione per qualsiasi cosa possa esservi utile
Andrea
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 migliorare le prestazioni?
Per le prestazioni, difficile darti una risposta precisa.
Relativamente al numero di record, posso dirti che 40.000 record sono pochi
per poter vedere andare un crisi un DBMS.
Posso dirti che ho database in Access con tabelle che arrivano quasi ad un
milione di record e non ho mai rilevato particolari problemi e/o
rallentamenti. Quello che conta, ovviamente, è recuperare tutti e soli i
dati che ti servono di volta in volta.
Da questo punto di vista (ma non solo) se sposti il tuo BE verso un DBMS
serio come SQL Server, allora hai maggiori strumenti che ti permettono di
ottenere il risultato voluto: recuperare tutti e soli i record che ti
servono di volta in volta.
Non sto poi a parlarti di tutte le possibilità che un vero DBMS ti mette a
disposizione: sicurezza, scalabilità, stored procedure, trigger,
transazioni.....
-- 
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 Andrea
Questo è uno dei classici casi in cui avere una FERRARI non significa essere
in grado di andare forte...!
Purtroppo il 90% delle prestazioni di qualsiasi DB(compreso JET) dipende
dall'ottimizzazione dei piani d'esecuzione e dalle metodologie di accesso ai
dati
e non ultimo dalla corretta strutturazione relazionale e
dall'indicizzazione... tutte cose
fortemente legate ma che nella media non sono nemmeno conosciute...!
I passi da fare sono molti(primo fra tutti lo studio, purtroppo non è
ammessa la superficiale conoscenza quando
si parla di OTTIMIZZARE prestazioni) per far funzionare bene un Server SQL
come si deve... altrimenti
si rischia di avere un DB(JET) solo più CAPIENTE e si finisce con il
lamentarsi di un DB che non fornisce prestazioni immaginate....!
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.alessandrobaraldi.it
---------------------------------------------------------------------------

 dati che ti servono di volta in volta.
Molto interessante il tuo post Gabriele...Posso innanzitutto chiederti in
che ambiente lavori, ovvero il db di cui parli lavora in rete e si in che
tipo di rete (ethernet, fastethernet...), e, altra domanda..., come pensi
che potrebbero essere le prestazione se questo DB lavorasse in modalità
desktop remoto con un server discreto dall'altra parte?
E, altra domanda...quali sono le tue tecniche migliori per "recuperare tutti
e soli i dati che ti servono di volta in volta."?
Grazie anticipatamente della tua risposta.


 Grazie anticipatamente della tua risposta.
Prego e complimenti per il terzo grado ;-)


 Ho sempre preferito distribuire il FE sui vari client.
Beh, puoi creare FE diversi per ciscun client
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access

 Beh, puoi creare FE diversi per ciscun client
Credo di avere perso un passaggio.
Stavamo parlando dell'utilizzo di una procedura MDB da parte di diversi
client che si collegano ad un Terminal Server.
In questo caso viene utilizzato lo stesso file MDB per tutti i client che
si collegano.
Si avrebbe la possibilità di fornire differenti file MDB se gli utenti da
remoto fossero distinti e, comunque, in questo caso quello si realizza è lo
stesso risultato che ho proposto io: la distribuzione di FE ad ogni client.
Dove sto sbagliando?


Gabriele Bertolucci" <"info[at]pbsoft[dot]it wrote:

nel aftto che vuoi usare lo stesso FE
Tu ha accesso con i TS al server.
bene tu accedi al front end C:\gabriele\Fe.mdb io invece C:\Massimiliano\Fe.mdb
entrambi in locale, ma ciascuno riefrito ad un solo user


 entrambi in locale, ma ciascuno riefrito ad un solo user
In questo caso, comunque, in caso di deployment di modifiche
all'applicazione, bisogna ugualmente copiare il nuovo FE nella cartella del
profilo di ogni utente configurato per i TS.
Giusto?


 e soli i dati che ti servono di volta in volta."?
Qui trovi indicazioni utili:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=281
Ma voglio farti un esempio pratico sul concetto "d'ottimizzazione" di cui ti
parlavano Alessandro e Gabriele.
Il mese scorso ho dovuto modificare una stampa che sviluppai dieci anni fa
con Access 97.
Il Report estrapolava i Totali Fatturato mensili per Clienti/Fornitori,
stampati in "orizzontale".
A quei tempi non avevo grande dimistichezza col Report Engine di Access e
utilizzai un metodo sicuro ma assai pesante:
- Impostai come origine dati Report una query che estraeva tutti i
Clienti/Fornitori
- Su evento formattazione del Corpo eseguivo una query che calcolava i
totali mensili per ogni Cli/For.
- Assegnavo tali totali a 12 textboxes Unbound sul Corpo del Report
Ciò significa che la query più importante veniva eseguita tante volte quanti
erano i Clienti/Fornitori in anagrafica...
Funzionava, ma con prestazioni che decadevano enormemente all'aumentare dei
dati...
Dovendo implementare delle nuove richieste, ho scelto il mese scorso di
rifare la logica dati della stampa: ora utilizzo una sola query a campi
incrociati come origine del Report che in un'unica "passata" calcola tutto.
Com'è ovvio che sia il guadagno di performances è incalcolabile.
E' solo un esempio, ma che a mio avviso sintetizza il 99% dei problemi di
performances dichiarati sui ng.
Saluti.


Perfettamente d'accordo ;-)
