Newsgroup: it.comp.appl.access
Titolo: Access2000 (MSDE) e Client/Server

Ho realizzato un'applicazione CS con Access2000 e data engine MSDE e fin qui
tutto ok. Ora ho dei problemi quando cerco di configurare l'apertura dei
recordset per un accesso remoto RAS.
Io mi aspetto di aprire un recordset "paginato", dove il server mantiene le
pagine e me le spedisce una alla volta nel lato client in base al movimento
del record corrente. Purtroppo non riesco a configurarlo (ammesso che ci sia
un metodo tra i vari adUseClient/adUseServer e adOpenKeySet/adOpenDynamic),
qualcuno mi puņ aiutare a capire come posso ottimizzare l'accesso ai dati
evitando di stare lģ ad aspettare che l'intero recordset venga scaricato dal
server prima che sia visualizzata la maschera ?
Mi rendo conto che potrebbe essere un problema un po' troppo avanzato ma
alla fine bisognerą pure che qualcuno lo affronti.
Grazie ancora per l'attenzione,
Andrea Censi
ace...@iname.com

 alla fine bisognerą pure che qualcuno lo affronti.
Cosa č avanzato? la gestione client/server?
Ciao, Sib

 Cosa è avanzato? la gestione client/server?
Rispetto alle domande standard nel ng mi sembra di si!


Premesso che non ho familiarità con Access2000 e MSDE mi pare
che quello che tu vuoi ottenere (ed anche io se è per questo!) è
una prestazione che travalica l' architettura Client-Server.
Cos'è la cosa bella di Access ? Le form bound.
Cos'è la cosa brutta di Access ? Le stesse form bound.
La vera forza di Access si trasforma nella sua più grande
debolezza quando si tenta di sviluppare applicativi per la rete;
utilizzando maschere che si collegano direttamente ad un fonte
dati (locale o client-server poco importa) il limite è dato dal
fatto che in ogni caso la form si scarica **almeno** tutta la
chiave primaria del recordset su cui è basata, se pensiamo
di fare una gestioncina remota di una tabella con 1M di
record la frittata è presto fatta (l' ottimizzazione e paginazione
dell' odbc non risolvono il problema).
Come ti accennavo non è che l' architettura CS introdotta
con MSDE migliori molto le cose, finchè la maschera
richiede tutto il dataset comunque il traffico di rete rimane
inaccettabile.
Soluzioni ?
L' unica a mia conoscenza è una struttura 3-tier, in cui
l' applicazione client dialoga costantemente con una
**applicazione** server (possibilmente installata sulla
stessa macchina su cui è presente il db-server x limitare
il traffico di rete); in questo caso sarà l'interazione tra
applicazione client ed applicazione server a fare in
modo che all' utente "sembri" di avere sottomano
tutti quanti i dati mentre in realtà gli vengono spediti
solo i record strettamente necessari (quello che vede
a schermo o poco più, un pochetto di buffering spesso
è fondamentale).
E' chiaro che per lavorare in questa architettura le
form bound uno se le deve dimenticare (e probabilmente
a questo punto sarebbe una scelta saggia dimenticarsi
anche Access); è altrattanto evidente che i sistemi
di sviluppo esistenti che lavorano su 3 livelli sono
o costosissimi (Progress ad esempio) o "scarsissimi"
(java con le sue servlet); ne consegue che potrebbe
essere una buona scelta implementarsene uno da soli.
Come ?
Una buona soluzione **potrebbe** essere:
DB-Server= MSDE
    E' "gratuito", robusto ed affidabile quanto SQLSrv,
   supporta fino a 5 utenti che sono perfino troppi in
   un' architettura 3-tier in cui il solo vero utente-db
   è l' application server stesso.
APP-Server= Applicazione Access
  Dialoga col DB-Server nella maniera consueta, mentre
 tutto il dialogo col client deve avvenire via DCOM o TCP
 tramite il winsock.ocx (decisamente meglio!), farà
 certamente un pesantissimo utilizzo di moduli di classe
 (una procedura persistente per ogni "maschera" aperta
 su ogni client) e di array (via tcp al momento mica ci si
 possono passare recordset, a meno di non scegliere
 una soluzione con RDO sull' http.... l' argomento merita un
 post tutto per sè).
Client= quello che ti pare
  Un' applicazione Access, un' eseguibile VB, qualsiasi
  cosa possa gestire un' interfaccia grafica ed il metodo
  di comunicazione prescelto con l'APP-Server.
Come ti dicevo non esiste sul mercato nessuno strumento
di sviluppo RAD in grado di lavorare su 3 livelli che costi
meno di qualche decina di milioni (java a parte, ma a me java
sta proprio antipatico e non voglio neppure prenderlo in
considerazione), bisogna decisamente scriversi una valanga
di codice :-((
Chi riuscirà ad affrontare (e risolvere) il problema che hai sollevato
con strumenti a poco prezzo come quelli elencati ed in maniera
sufficientemente "aperta" da non esser costretto a riscrivere
tutto quanto alla prima novità MS farà certamente grandi cose
(e probabilmente parecchi soldini); in bocca al lupo.
Bye, Ste

Penso che si possa fare anche senza un'architettura 3-tier (non stiamo a
scomodare programmazione di socket o interfacce RPC MIDL) forse ci si può
riuscire gestendo i forms in modalità unbound ed utilizzando RDO che mi
sembra riesce benissimo a bufferizzare in pagine i recordset (o resultset
come li chiama). Chissà cosa costava a M$ aggiungere la gestione di pagine
in recordset ADO così come ha fatto per RDO (che tra l'altro è un antenato
di ADO).
Ho fatto una prova e sembra funzionare.
Andrea Censi
ace...@iname.com

 scomodare programmazione di socket o interfacce RPC MIDL)
Permettimi di dissentire. Per cominciare con il 3-tier basta molto meno: un
poco di codice asp, tanto per cominciare. Ho visto scrivere codice di un
tale livello su questo NG che non credo proprio possa spaventare molti
aprirsi ad un poco di vbscript con oggettini server.
Se poi si vuol sempre continuare a fare tutto in access allora ognuno pianga
sul latte che versera' ;-)
Ciao, Fabio Zed Zamparelli


Certo che con RDO si può fare, RDO **è**
un' implementazione 3-tier; non lasciarti trarre
in inganno dal fatto che usi il server di "default"
che t'ha fatto mamma MS; l' unica differenza è
che invece di passare per un protocollo sensato
fanno transitare i dati sull' http (sigh!).
Appena comincerai ti accorgerai immediatamente
di come sia indispensabile (per motivi prestazionali),
andare un pochetto oltre; sensa scrivere delle procedure
lato server ogni volta che il client chiede una "pagina"
di record o deve lockarne un' altro il server deve
riaprire il recordset e riposizionarsi.... e ti ritroverai
+o- punto e a capo.
Occorre considerare inoltre gli indubbi benefici
di avere degli "oggetti" lato server (logica riutilizzabile
a prescindere dall' interfaccia, interfaccia leggera ecc. ecc.)
C'è di che lavorare indubbiamente molto.
Bye, Ste

 +o- punto e a capo.
Grazie del suggerimento l'obiettivo è quello di poter utilizzare
un'applicazione già esistente mediante un collegamento RAS senza aspettare
che venga scaricato sul client tutto il recordset ogni volta che si
visualizza una maschera. Con RDO ho ottenuto il risultato inizialmente
prefissato, ora effettuero' delle ulteriori prove per testarne le
prestazioni in operazioni canoniche di ricerca/modifica dati.
Per ora le prestazioni sono più che soddisfacenti (sempre parlando di RAS).


Bhè, se parli di RAS significa che il problema è circoscritto a 1 o 2 utenti
che si collegano in remoto via modem, in questo caso anche la più
semplice delle implementazioni RDO è sicuramente sufficiente.
Il ragionamento partiva da un presupposto di più ampio respiro, della serie
"come implementare un gestionale da 20-30 utenti con Access" o cose
del genere; dubito che 1-2 utenti possano "inchiodare" un db sql7, per
quanto
si sforzino di aprire/chiudere dataset....
Bye, Ste