Newsgroup: it.comp.appl.access
Titolo: LIMITI TABELLE COLLEGATE

Ho un gestionale sviluppato in VB con DAO che si aggancia a SQLServer
tramite tabelle collegate di Access 97.
Volevo sapere ci sono dei limiti su questa architettura?
O meglio, sono convinto che ci sono dei limiti per esperienza, ma non
riesco a trovare documentazione che mi dica:
- quanti accessi concorrenti può supportare access con questa
architettura?
- Quali sono i limiti documentati di questa architettura?
Devo giustificare che questa architettura fa pena.

 Devo giustificare che questa architettura fa pena.
Colpa di chi l'ha scritta.
Ciao.

 ha scritto nel messaggio
news:8ef00b7a.05012...@posting.google.com...


 (anzi, diciamo pure che non la documenta affatto) e quindi ti devi
Se ti riferisci all'Help di Access  č verissimo.
Ma se parliamo di documentazione cartacea il discorso cambia, e molto.
Sono stati scritti dei bei tomi di programmazione Access/ODBC + SqlServer
... con tutto ciň che serve per creare vere applicazioni Client-Server.
Ovviamente per riuscire nell'intento č necessario cambiare la logica delle
applicazioni convertite da Jet e tener conto delle esigenze del driver ODBC,
per la risoluzione delle Query sul Server invece che sul client.
Cosě come č essenziale avere familiaritŕ con ODBC Direct e l'SQL del server
in generale.
Il secondo link MS che hai postato č una buona base di partenza.
Ciao.

 Ciao.
E te credo! Non abbiamo molte chances.
Ciao.
--
Simplex2
www.mdenittis.it

 casa editice  e/o rivista o sito.
La prima risorsa, in Italiano che ho sfruttato a fondo è stata (ai tempi di
Access 97, quindi non so se sia attualmente in commercio):
"Microsoft Jet Database Engine Guida del programmatore"
Dan Haught
Jim Ferguson
ISBN  8871318587
Ottimo, sia per la programmazione con JET, che per la progettazione di
applicazioni ODBC + SQL Server.
Buono il CD allegati con molti esempi pratici.
E poi:
Client/Server Programming with Access & SQL Server: The Integrated Guide for
Programmers & Developers
Leo Sanin, Renzhong Chen
ISBN: 1566046939
Lo acquistai in lingua Inglese su suggerimento di un collega di lavoro:
notevole.
Ciao.

 che discrete:
[CUT].... mi sa che ci ha preso per sprovveduti ......
Non ci siamo proprio capiti, eh?
Va bene lo stesso.
Grazie per i titoli dei testi, ne farò tesoro.
Ciao.
--
Simplex2
www.mdenittis.it

 Non ci siamo proprio capiti, eh?
Certo che ti ho capito ... al volo: se hai problemi di prestazioni con un
solo PC collegato al server, non ci sono tabelle collegate su cui scaricare
responsabilità.
Non ti prendo per sprovveduto, ma ti consiglio ti mettere in discussione le
tue certezze.
Ciao.

 tue certezze.
Carissimo, la questione che non riesco a far evincere è quella che se due
persone (me e Massimo)
hanno avuto lo stesso problema, ovvero cercare di dimostrare, anche con
documentazione e con test sperimentali, che una tecnologia appare essere
meno prestante di un'altra, significa che queste due persone si sono trovate
di fronte a cose già fatte, altrimenti il problema non  se lo sarebbero
posto perchè, forse per convinzioni personali non necessariamente corrette,
avrebbero scelto una soluzione diversa.
OK?
Nel mio caso personale, esisteva (esiste ancora, grazie a Dio) un bel DB
copioso (molto copioso) intorno a cui gravitavano decine di applicativi
(molti dei quali sviluppati con Access) e proprio per questa inflorescenza
di applicativi che non mi era neanche passata per l'anticamera del cervello
di rivedere la struttura del DB. Le prestazioni di alcuni di questi
applicativi erano piuttosto scarse, specialmente quando risiedevano a valle
di un paio di router dal server. Il fatto sensibile (e dimostrato coi fatti)
era che se eseguivi una query access ad una tabella collegata, ottenevi
determinati tempi di risposta, se la lanciavi come query pass-trough o la
eseguivi con MSQuery o con i client tools dell'RDBMS (ovviamente dalla
stessa postazione), i tempi erano sensibilmente inferiori.
Mi dirai: "non è normale e implica problemi di progettazione/programmazione
a monte" (cito le tue testuali parole). Vabbè, e allora? Ammesso e non
concesso che il DB faccia anche schifo, rimane il fatto che, a parità di
condizioni, le query sulle tabelle collegate erano meno prestanti!
Che ci vuoi fare?
Saluti.
--
Simplex2
www.mdenittis.it

 Che ci vuoi fare?
Non prendere le mie risposte come polemiche fini a se stesse.
Se, come sospetto, le vostre esigenze riguardano LAN con qualche PC in rete
non *dovete* avere problemi di prestazioni: sia con JET che con ODBC.
Se li avete li potete risolvere.
Ciao.

 infami di applicazioni Access perfino in monoutenza: e allora?
E allora mi attacco e tiro forte! Il sistema a monte l'ho trovato bell'e
fatto e modificarlo significa darsi una successione esponenziale di
martellate nei perpendicoli!
[CUT]
Perchè, scusa, non scrivi un piccolo (non troppo stringato) TUTORIAL
sull'argomento, in cui introduci a volo d'aquila la questione e fornisci i
riferimenti per approfondimenti. E' un buon modo per far avvicinare il
lettore interessto alla materia senza, necessariamente, scrivere un
trattato!
Se lo scrivi (e me lo consenti) lo inserirei nella sezione 'documentazione'
del mio sito.
Simpaticamente, Ciao.
--
Simplex2
www.mdenittis.it

 ha scritto nel messaggio
news:ctadrc$99u$1...@canarie.caspur.it...

Interessante quanto già trattato argomento...!
Mi permetto di avvallare pienamente quanto detto da Oscar(anche se non
ha bisogno di difensori) per il semplice motivo che io nel mio tempo libero
agli albori di Access ho perso qualche ora di tempo a capire come
ottimizzare
i criteri di gestione dei dati.
Ci sono testi in inglese che spiegano come ottimizzare l'uso di Indici per
una
più pronta risoluzione delle Query, di come non usare funzioni di
aggregazione
sui domini(DCOUNT, DLOOKUP e fratelli vari) ma di sostituirle con SubSelect.
Posso darti un link dove trovi ottimo materiale di come ottimizzare le Query
tramite SHOWPLAN:
http://builder.com.com/5100-6388-5064388.html
Purtroppo quando all'inizio del post dicevo che l'argomento era stato altre
volte dibattuto intendevo dire che spesso chi non ha avuto esperienze
personali di queste cose non è abituato ad usare i criteri Normalizzati
di strutturazione di un DB, di conseguenza la prima lamentela è di LENTEZZA
di impossibilitò di uso con più di 2 utenti, di eccessiva lentezza di
esecuzione
delle Queries.
Questo non significa che siano considerazioni corrette anche se sollevate da
10
persone, significa che quelle persone possono commettere lo stesso tipo
di errore o avere considerazioni non spinte all'ottimizzazione per mancanza
di esperienza.
Il fatto poi che ci si trovi a dover lavorare con prodotti già fatti è
normale che sia
anche un pò frustrante, ma i casi sono solo 2:
1)Accettare i limiti
2)Ristrutturare il tutto
L'errore più frequente poi che spesso mi è capitato di notare è che per
risolvere
i probelmi di lentezza di Access(JET) si usi l'UpsizeTool per il passaggio a
SQL(MSDE).
Ti assicuro che i problemi non verranno risolti, anzi saranno dolori, perchè
lavorare con un
SERVER SQL impone di abbandonare la mentalità delle Queries lato Client a
favore di
StoredProcedure estremamente performanti in quanto elaborate lato Server.
Quando Oscar parla di poca scalabilità della connessione ODBC è vero, anche
se
non presenta grandi problemi, solo che, dando uno sgurado a OLE+ADP viene
facile vedere i vantaggi.
Tutte queste considerazioni io le ho trovate nel web, leggendo libri e
soprattutto
leggendo sempre tutti i POST dei NG di Access in particolar modo quelli
americani
senza togliere nulla ai nostri.
Un saluto
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------