Newsgroup: it.comp.appl.access
Titolo: Da Access a SQL

Salve
Ho un db in sql server
In Access ho le tabelle collegate e ho creato query, maschere, report per
visualizzare delle statistiche.
Il problema è che le query in Access sono composte da varie tabelle in
relazione tra di loro e diverse query hanno al prorpio interno altre query.
Risultato che le query per essere eseguite richiedono diverso tempo.
Volevo a questo punto creare della query in sql (viste o stored procedure)
per far si che i risultati mi siano restituiti piu' velocemente.
Ho due domande:
Creando viste o stored procedure il rislutato è piu' veloce o non dovrei
trovare enormi differenze??
Nelle query di access ho nella griglia criteri diversi valori come questo:
Between [Forms]![mia scheda]![DATADAL] And [Forms]![mia scheda]![DATAAL]
dove mi prende due date da una maschera aperta.
Se io creo una vista o una stored procedure come faccio a passargli
parametri come questo che vengono presi da una maschera in Access ???
Grazie
Ciao
Giorgio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio 
news:ec52g4$vn3$1...@news.newsland.it...


> Giorgio
Io prima di tutto cercherei di ottimizzare le query e il database in Access 
ad esempio:
- aggiugendo nelle tabelle indici che potrebbero velocizzare le query;
- eliminando le subquery;
- controllando che i join tra le tabelle siano effettuati con campi interi 
che sono più efficienti.
In ogni caso il passaggio a Sql non è affatto indolore, ma dà alla fine 
ottime prestazioni e comporta un enorme incremento di prestazioni nell'uso 
in rete
Attualmente hai le tabelle di Sql collegate tramite Odbc? Se è così allora 
il calo delle prestazioni potrebbe non essere colpa delle query.
In passato ho voluto fare la prova con un mio programma: ho importato le 
tabelle da access a sql, le ho collegate tramite odbc lasciando le query 
intatte. Il programma si inchiodava spesso senza motivo e aveva una lentezza 
paurosa, molto più lento della versione tutta in access. Il salto di qualità 
si ha passando ai progetti di access (.adp) in cui anche le query sono su 
sql, in quel caso le prestazioni migliorano
Ungi

 Ungi
Ciao,
mi inserisco sull'argomento c x' ci sto lavorando anch'io in questi
giorni.
La mia domanda è semplice: eseguendo un usize da access a SQL srv che
dia
come risultato non un progetto Access ma un mdb con tabelle collegate
(via ODBC),
si sta usando ancora il motore JET vero? Cioè, chi esegue qurery,
vigila sulle regole
di integrità ecc è sempre JET e no il motore SQL srv.
Se è cosi' quali sono i vantaggi dio un upsize di questo tipo?
Grazie.
Alberto

Alberto
Può essere un primo passo verso il mondo Sql Server
Facendo l'upsize delle sole tabelle basta collegarle e le applicazioni 
create per il solo Access funzionano da subito perchè le query rimangono le 
stesse e continuano ad essere eseguite in locale usando JET
Altri scenari potrebbero essere la necessità di sviluppare in fretta una 
applicazione basata su tabelle Sql già esistenti (magari create da altri) ma 
si conosce solo Access, inoltre con Odbc è possibile continuare ad usare DAO 
invece di ADO,
oppure la necessità di utilizzare funzionalità di tabella inesistenti in 
Access (ad esempio i campi calcolati o i trigger), o semplicemente il voler 
avere i dati gestiti da un motore di database più potente e sicuro
Mediante Odbc le query vengono eseguite in locale e quindi NON sfruttano le 
potenzialità Client-Server, in questo caso Sql Server si comporta come un 
semplice file server
Le regole di integrità del database invece vengono gestite da Sql Server 
perchè è lui che le ospita
Un successivo passo potrebbe essere l'uso di Query Pass-Through che 
necessitano della sintassi T-Sql e vengono eseguite direttamente da Sql 
Server
Nei progetti adp alla fine il motore Jet non esiste più e si possono usare 
solo tabelle e query sul server, ed è qui che avviene, per le applicazioni 
in rete il salto di qualità in termini di prestazioni (per applicazioni 
stand alone secondo me non è giustificato il passaggio al formato adp per 
esigenza prestazionali)
A presto
Ungi 


Grazie 1000.
Sei stato molto chiaro.
A presto.
Alberto