12/02/2025 - Catafirro ha scritto:
12/02/2025 - amorosik ha scritto:
Ah capisco, quindi alcune form sono collegate a delle query pt
Quando vuoi modificare una riga, carichi dal db centrale il record incriminato e lo metti nella tabella fisica locale, che alimenta la form di modifica/visualizzazione
Se tocchi qualcosa a video, o se vengono eseguite modifiche da codice, poi quando vuoi salvare mandi tutto il record presente in tabella locale verso il db centrale
E ritorna il quesito iniziale, qual'e' l'utilita' della tabella locale? Perche' non carichi tutto solamente a video? Oppure su un recordset ado in ram, collegato alla form?
Spero porterai pazienza per l'insistenza, ma non riesco ancora a capire l'utilita' delle tabelle fisiche sui client
-
"..spingere verso qualcosa per la quale non è stato progettato.."
a che operazione ti riferisci esattamente?
Con l'associazione di una tabella locale alla form non faccio altro che assecondare la natura di Access. Avrei potuto ottenere un risultato simile associando un recordset ADO (non la tabella remota, che non linko), ma durante il disegno non avrei potuto usufruire del vantaggio dei campi connessi, e durante il debug non avrei potuto consultare in modo semplice le tabelle sottostanti. Devi pensare al caso complesso di una tabella testata più varie tabelle dettagli, In molti casi, prima dello scaricamento dei dati modificati su server, è necessaria una loro elaborazione da codice. Questa è facilitata dal fatto che il codice può operare su tabelle fisiche, con maggior comodità e sicurezza.
Access è stato progettato per un uso amatoriale, poi via via è stato arricchito. La gestione delle tabelle remote linkate funziona bene quando sono anch'esse del tipo Access, ma ci sono limitazioni quando sono di altro tipo. Ricordo ai tempi la connessione a tabelle DBF, molto lenta, che mi pare, ma potrei sbagliarmi, non usava gli indici. Ma il vero problema delle tabelle linkate si ha con i classici db client-server, come SqlServer o MySql, poiché la gestione a carico del server non viene sfruttata. Se fai una query con WHERE e JOIN contenente tabelle linkate, i dati di tutte le tabelle remote coinvolte vengono caricate in locale dove è access che risolve where e join, con scadimento drammatico delle prestazioni al crescere del numero dei record coinvolti,
In lettura il rimedio può essere quello di query pass-through o di query definite su server e linkate come fossero una tabella. Io ho adottato la prima soluzione per la sua flessibilità, visto che posso giocare con le stringhe sql. In entrambi i casi where e join vengono risolti dal server, che manda solo i record risultanti. Oppure si possono usare i recordset ADO, che fanno lo stesso lavoro. I recordset ADO sono da usarsi anche in scrittura, con parecchi vantaggi rispetto a recordset DAO su tabelle linkate. Uno è un miglior uso delle transazioni, che vengono gestite dal server tramite la connessione.
Mi sono dilungato a beneficio di chi conosce poco Access.
"..ma durante il disegno non avrei potuto usufruire del vantaggio dei campi connessi,.."
Durante la fase di progettazione basta collegarsi alle tabelle db MySql, ed hai gli stessi identici vantaggi, non e' necessario avere tabelle locali
Poi quando tutto e' definito e lo metti in produzione allora puoi tenere degli equivalenti recoset ado in memoria, avere dei doppioni (alcune db duplicate in locale contenenti dati che sono presenti sul db principale) mi sembra altamente rischioso
.
"..Questa è facilitata dal fatto che il codice può operare su tabelle fisiche, con maggior comodità e sicurezza.."
Vedi sopra, durante la progettazione 'colleghi' a tabelle MySql, nell'uso reale colleghi a recordset Ado in ram
.
"..Se fai una query con WHERE e JOIN contenente tabelle linkate, i dati di tutte le tabelle remote coinvolte.."
E' chiaro che se stai usando un db server remoto non e' mai consigliabile tirare su tutto sul client e poi far smazzare la query al motore locale, e' da suicidio se la dimensione dei dati coinvolti e' importante, in quel caso fai la tua bella query pt la mandi e tiri su solo il risultato, credo sia la norma quando si usa un db server remoto rispetto ai client
E' altrettanto chiaro che finora l'utilita' delle tabelle fisiche locali non si e' ancora vista, o meglio non la vedo io
Mi sembra che tu stia tirando la discussione sugli ovvi vantaggi di una query complessa da inviare al db server, ma non e' questo il punto
Il punto e' quale sia la reale necessita'/utilita' delle tabelle fisiche in locale
.
"..Mi sono dilungato a beneficio di chi conosce poco Access.."
Certo, e personalmente ti ringrazio del tempo speso, come per tutti quelli che rispondono ai quesiti e cercano per quanto possibile di aiutare
E dal mio punto di vista e' sempre molto utile confrontarsi al di fuori della propria 'parrocchia' per capire come operano altri sviluppatori sugli stessi strumenti che usi anche tu, ma devo dire che non condivido il modo di operare che hai descritto, mi sembra di violare uno dei comandamenti sostanziali del sistema informatico dove l'unicita' delle informazioni deve essere mantenuta con cura