L'uso di tabelle locali, immagine delle tabelle remote, associate alle form ha il vantaggio di una maggior flessibilità. Ogni tabella locale può essere ampliata con l'aggiunta di campi di servizio da riempire al momento della lettura da server. Le elaborazioni finali prima del salvataggio su server possono essere fatte in locale (per esempio la rinumerazione dei dettagli) con successivo scaricamento su server, stressando di meno il db remoto.
Elenco le fasi di una modifica di record.
1. Viene letto il record da server tramite un recordset ADO di sola lettura con riempimenti della tabella locale. La form è in modalità solo lettura, i campi sono bloccati. Si tratta di operazioni di sola consultazione molto frequenti nel mio caso.
2. Quando l'utente decide di modificare, clicca sulla funzione EDIT. Viene riletto il record da server e la form diventa modificabile. Vengono memorizzati due campi presenti su ogni tabella, chiave user e datetime dell'ultima modifica.
3. L'utente fa le sue modifiche sulla tabella locale. In questa fase non c'è alcuna interazione col record remoto.
4. L'utente decide di salvare le sue modifiche e clicca sulla funzione SAVE. Si ha l'accesso al server con un recordset ADO di lettura scrittura. Prima di dare il via alla transazione (che potrebbe comprendere sia il salvataggio di testata+dettagli sia la modifica di altre tabelle dipendenti, come un saldo su un conto da prima nota), si controlla il valore del campo attuale dell'ultima modifica. Se è cambiato rispetto al momento dell'edit, si avverte che non è possibile consolidare le modiche poiché lo user tal dei tali ha intanto modificato a sua volta. In questo momento si possono eventualmente salvare negli appunti modifiche lunghe, come annotazioni ecc... Viene rinfrescato il record e l'utente ripete le modifiche. Si tratta però di situazioni molto rare che non hanno mai provocato proteste nei miei clienti.
5. Si dà il via alla transazione scaricando su server i dati locali. Vengono anche aggiornati i due campi user e datetime di modifica. La form torna in modalità solo lettura.
Come si vede la fase della transazione con blocco dei record è minimizzata, e non è soggetta ai capricci dell'utente, che non fa danno se lascia la form in edit andando a prendersi un caffé. Deve solo pagare lo scotto, però ripeto molto raro, di essere stato intanto preceduto da qualcun altro che gli ha fatto perdere le sue modifiche.
Un altro vantaggio è nel debug. Le tabelle locali sono facilmente consultabili con gli strumenti access. Dimenticavo di dire che le tabelle locali non sono usate direttamente, rimangono sempre vuote. Per ogni form che viene aperta, viene generata al volo un'immagine con nome random e usata quella. Il che consente di gestire anche le form che si aprono in multi istanza.
Altra cosa, le tabelle remote non sono linkate, l'accesso avviene solo attraverso i recordset ADO, oppure tramite query pass-through per le consultazioni.
Il sistema può apparire complesso, ma opportune funzioni aiutano a scrivere relativamente poco codice.