Da Access a SQL

[Giorgio M]

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

[Graziano]

Sulla velocità non mi esprimo, i fattori da prendere in considerazione non
sono pochi.
Sulla fattibilità, x access 2000 si usano i progetti ADP e si puo' fare
l'upsize guidato.

Per programmare i forms nel riquadro dati c'e' una voce x i parametri ma non
so aggiungere molto altro...

Post by Giorgio M
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.
Creando viste o stored procedure il rislutato è piu' veloce o non dovrei
trovare enormi differenze??
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

[Ungi]

Post by Giorgio M
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.

L'elaborazione è fatta tutta su un solo pc oppure l'elaborazione è fatta in
rete locale?
(Se i dati risiedono su un pc diverso da quello che esegue le query con Sql
Server si hanno immediati vantaggi)

Post by Giorgio M
Creando viste o stored procedure il rislutato è piu' veloce o non dovrei
trovare enormi differenze??

In generale trovo il motore di Sql un pò più performante, ma sono sensazioni

Post by Giorgio M
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 ???

Ovviamente in una query sql non puoi fare riferimento a maschere, però puoi
usare le funzioni definite dall'utente che possono accettare dei parametri e
che puoi richiamare da una maschera di access

Post by Giorgio M
Grazie
Ciao
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

[all]

Post by Ungi
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

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

[Ungi]

Post by all
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

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

[all]

Post by Ungi

Post by all
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

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