Newsgroup: it.comp.appl.access
Titolo: Passaggio a SQL Server dei dati

Sto facendo delle prove di passaggio da un MDB as SQL Server.
Come prima prova ho passato direttamente senza modifiche particolari
(con upsizing tool) con DAO da Access97 e ho allegato le tabelle via
ODBC.
Ho corretto i due o tre problemini legati alle chiavi univoche in un
paio di tabelle che non le avevano.
Funziona perfettamente.
I tempi di risposta sono invece pietosi (anche in rapporto 1 a 4
rispetto all'accesso ad un MDB su un server di rete), prove su un
singolo utente con una query su tre tabelle in N a N.
Evidentemente mi aspetto un minore rapporto all'aumentare degli utenti
e dei dati.
Naturalmente so bene che senza modifiche potevo aspettarmi qualcosa di
simile, anche se mi aspettavo una minore penalizzazione nei tempi nel
'passaggio brutale'.
Tanto per cominciare le Query e le istruzioni SQL mi sembra di aver
capito le devo 'sparare' come Pass Trought (se non sbaglio).
Le funzioni integrate devono anch'esse essere sparate come stored (se
e' possibile) o essere gia' presenti.
A questo punto qualcuno queste prove evidentemente le avra' gia fatte
chi mi da' dei consigli o dei piccoli esempi di codice.
Sparare una Query a SQL Server quanto penalizza nei tempi rispetto ad
eseguirne una gia' presente ?
In pratica mi converrebbe fare un meccanismo (se il sistema esiste)
che passi automaticamente al Database Server tutte le Query rendendole
disponibili a tutti una volta per tutte.
Tutto cio' che e' invece parametrico la lancerei inviando la query
come Pass Trough.
Che mi dite?
Che ne pensate ?
----------------------------------------------------------
Paolo Hölzl
Gruppo Tekup Software developer (Bologna)
----------------------------------------------------------
ATTENTION!, antispam 
For reply, substitute xxx with gruppotekup

Che mi dite?
Quello che tu chiami "sparare la query al server" e le query
pass-through sono la stessa cosa (se ho capito quello che vuoi dire).
L'unico cambiamento logico che devi fare, e' quello di far eseguire il
lavoro al server anziche' al client (Access). Al momento tutto e'
mostruosamente piu' lento perche' stai usando SQL server solo come
sorgente di dati, mentre il lavoro viene ancora fatto da Access.
Se vuoi "memorizzare" le tue query nel database, lo puoi fare sia in
forma di view (query di select) oppure di stored procedures, ma ti
devi riscrivere il loro codice in ogni caso. Non scendo di piu' nel
dettaglio perche' gia' cosi' potrei aver detto cazzate :-) (per ora ho
usato SQL server solo per qualche test)
-- 
Ciao,
Giovanni

Giovanni Albertone wrote:

il vantaggio prestazionale lo ottieni difficilmente se continui a fare
lavorare jet con le tabelle collegate, o  le query in pass-through su fonte
odbc.
Per velocizzare le cose dovresti creare un componente (Activex) che,
installato sul server, ti esegue le query (o le store procedure) su sql
server, e ti ritorna degli oggetti recordset (magari ado....).
E' un pň piů complesso ma i risultati ripagano gli sforzi.

Concordo con Giovanni, per quanto io non abbia esperienze serie con SQL
server,
man con altri DB client server si,  e il problema consiste proprio in
questo, se le query le passi al server e gliele fai eseguire è una cosa
altrimenti...... e poi tieni conto che access con
tabelle allegate con database client/server è lento da morire... sempre.
Se non vuoi buttare via tutto potresti fare così, se ha maschere che leggono
dati direttamente da un tabella ODBC, crea una tabella di appoggio locale
quando apri la maschera e lavora su quella... fa un po schifo però almeno
non devi riscrivere tutto.


Scusa ma hai controllato gli indici? Dalla mia esperienza SQL SERVER è
notevolmente più veloce di Access non fosse altro che per il fatto che si
tratta di una applicazione Server e cioè vengono ritrasmessi solo i dati che
verificano la query. Per quanto riguarda l'accesso via tabelle collegate o
query di tipo passtrough la differenza non è molta...
Ciao Nicola

query di tipo passtrough la differenza non è molta...
Naturalmente i test di preformance l'ho fatto su tre tabelle
correttamente indicizzate e legate relazionalmente.


non devi riscrivere tutto.
Impensabile sia per tempi di risposta che per dimensioni dei dati da
trasferire, per non parlare poi dei problemi di lock e altro.


devi riscrivere il loro codice in ogni caso. 
E' questo che trovo inconcepibile, ci deve essere qualcosa che aiuti.
A di la del problema di prestazioni attualmente i programmi di test
che ho fatto lavorano su SQL Server o su MDB con lo stesso codice
semplicemente scegliendo l'origine dati.
Quello che vorrei fare e' un 'tasto' che spara stored query e
procedure al database Server in modo sostitutivo rispetto a quelle
eventualmente gia' presenti).
Vorrei quindi far si' di continuare ad operare con le tabelle allegate
e sostituire Openquery con una funzione che opera lanciando una query
in locale e in caso di collegamento a SQL Server lancia invece una
stored Query o invia la Query al Server come Pass-Trought.
