Form che si sfasciano

di il
22 risposte

Form che si sfasciano

Ciao a tutti.

Ho una grossa applicazione in Access interfacciato con MySql. Uso molto le tabelle locali DAO, sulle quali scarico i dati da server con ADO. In pratica le form sono legate alle tabelle DAO locali, e solo dopo l'elaborazione i dati vengono inviati al server tramite ADO. Molto spesso le form si sfasciano, e non si aprono più dando un errore 2001. Per ripristinarle è sufficiente aprirle in modalità design e da lì farle partire. Così partono e magicamente si rimettono a posto.

Qualcuno ha idea di dove possa stare il problema?

22 Risposte

  • Re: Form che si sfasciano

    Hai controllato innanzitutto se ci sono problemi riferibili a qualche riferimento che punta a librerie mancanti?

  • Re: Form che si sfasciano

    Form che si sfasciano? Poverette.  Che cosa intendi per “si sfasciano”? Potresti indicare la descrizione dell'errore 2001? Dici che aprendole in visualizzazione struttura poi riprendono a funzionare. Devi fare qualche modifica o è sufficiente aprire in struttura e tornare alla vlsualizzazione normale? Quando esci dalla visualizzazione struttura ti chiede di salvare anche se tu (magari) non hai fatto modifiche?

    Hai detto che è una grossa applicazione in Access. Supera forse il limite dei 2 GB durante l'esecuzione? Il problema si è presentato fin da subito o all'inizio funzionava e solo ad un certo punto ha iniziato a sfasciarsi? Prova a trasferire tutto in un nuovo file e/o fare il /DECOMPILE. Il file è usato in postazioni diverse? In questo caso danno tutte lo stesso problema o solo alcune? In caso di uso su più postazioni, ognuna ha un suo file (caldamente consigliato in locale) o condividono tutte lo stesso file?

  • Re: Form che si sfasciano

    01/11/2024 - Catafirro ha scritto:


    Ho una grossa applicazione in Access interfacciato con MySql. Uso molto le tabelle locali DAO, sulle quali scarico i dati da server con ADO. In pratica le form sono legate alle tabelle DAO locali, e solo dopo l'elaborazione i dati vengono inviati al server tramite ADO.

    Scenario ‘interessante’ : come gestisci la multiutenza (sempre che esista)?

    Per il resto attendo le risposte alle osservazioni fatte da Phil …

  • Re: Form che si sfasciano

    01/11/2024 - max.riservo ha scritto:


    01/11/2024 - Catafirro ha scritto:


    Ho una grossa applicazione in Access interfacciato con MySql. Uso molto le tabelle locali DAO, sulle quali scarico i dati da server con ADO. In pratica le form sono legate alle tabelle DAO locali, e solo dopo l'elaborazione i dati vengono inviati al server tramite ADO.

    Scenario ‘interessante’ : come gestisci la multiutenza (sempre che esista)?

    Per il resto attendo le risposte alle osservazioni fatte da Phil …

    Con l'età diventi sempre più elegante e diplomatico… ;-)

    Il termine "interessante" è interessante… 

    La cosa più interessante è soprattutto quando andrà a sparare le tabelle locali nel server… 

    Se ho capito bene sovrascrive tutte le tabelle…?

    In ordine da rispettare le relazioni…? 

    Temo che così strutturato la multiutenza potrebbe essere un tantino in crisi… ma è una mia opinione.

    Usare le vecchie Linked non sempre è cosi interessante.

  • Re: Form che si sfasciano

    01/11/2024 - @Alex ha scritto:


    01/11/2024 - max.riservo ha scritto:


    01/11/2024 - Catafirro ha scritto:


    Ho una grossa applicazione in Access interfacciato con MySql. Uso molto le tabelle locali DAO, sulle quali scarico i dati da server con ADO. In pratica le form sono legate alle tabelle DAO locali, e solo dopo l'elaborazione i dati vengono inviati al server tramite ADO.

    Scenario ‘interessante’ : come gestisci la multiutenza (sempre che esista)?

    Per il resto attendo le risposte alle osservazioni fatte da Phil …

    Con l'età diventi sempre più elegante e diplomatico… ;-)

    Il termine "interessante" è interessante… 

    La cosa più interessante è soprattutto quando andrà a sparare le tabelle locali nel server… 

    Se ho capito bene sovrascrive tutte le tabelle…?

    In ordine da rispettare le relazioni…? 

    Temo che così strutturato la multiutenza potrebbe essere un tantino in crisi… ma è una mia opinione.

    Usare le vecchie Linked non sempre è cosi interessante.

    Diplomatico è possibile, per l'elegante nutro forti dubbi ;-)

    La curiosità per questo post nasce dall'utilizzo di Access con MySQL, che già non è così frequente, in una modalità addirittura fuori dal comune ovvero ‘interessante’ : l'autore parla di un'architettura che potrebbe avere un suo perché (io penso a personale tecnico fuori sede che non ha disponibilità di connettività e che deve comunque caricare dei dati di interventi/misure su DB. Lavorando in modalità ‘disconnessa dal server’ su una copia locale dei dati  e poi effettuando un ‘resync’ quando si ha a disposizione la connettività potrebbe essere una strada anche se MS ci provò con le repliche ai tempi di Access2000 e poi abbandonò l'idea).

    Poi personalmente penso che sia una strada che crea più rogne che benefici (difficile stabilire chi abbia ragione nel caso di aggiornamenti sugli stessi record da parte di persone diverse) però hai visto mai che l'OP abbia trovato una soluzione accettabile …

  • Re: Form che si sfasciano

    Max c'è poco da inventare….ma lo sai meglio di me quali sono i problemi di creare un sistema di resync asincrono… da Offline… 

    In ogni caso vediamo se il caso cui cenni rientra nell'esigenza dell'utente… o se l'impostazione ha scopi e ragionamenti differenti.

  • Re: Form che si sfasciano

    Chiedo scusa per il ritardo con cui rispondo, non ho esperienza con i forum, ero scettico sul fatto che la mia richiesta sarebbe stata presa in considerazione e me ne ero proprio dimenticato, in mezzo ai mille problemi che tutti voi programmatori ben conoscete. Vi descrivo lo scenario in cui si verifica il problema, Si tratta di un'applicazione risalente a 25 anni fa impostata nel classico modo Frontend/Backend con tabelle linkate. E' in uso presso una ventina di clienti, da piccoli a grandi, fino a una quindicina di stazioni. Ci sto lavorando da parecchio tempo per adeguarla ai tempi, convertendo tra l'altro il backend da access a MySql. Sono arrivato si può dire in fondo, entro l'anno dovrebbe partire il primo cliente. 

    Le form sono essenzialmente di tre tipi: gestione archivi (con le classiche funzioni di inserimento, modifica, cancellazione), interrogazioni (subform di composizione filtro e sheet di presentazione dei risultati), procedure esecutive (tipo generazione fatture, per intendersi). Vi descrivo una gestione di tabella, come da figura.

    A destra abbiamo una subform linkata alla tabella reale MySql. Sulla sinistra abbiamo la form principale linkata a una tabella locale access che è l'immagine della stessa tabella MySql. Ad ogni spostamento di record sulla subform a destra corrisponde la lettura del record e il suo inserimento nella tabella locale, che contiene sempre e solo un record (quindi viene eliminato il precedente prima di inserire quello nuovo).

    I dati non sono modificabili fino a quando non si schiaccia il bottone EDIT del menù Ribbon. Le modifiche avvengono sulla tabella locale. Quando l'utente ha finito schiaccia SAVE e un codice aggiorna il corrispondente record MySql, mentre la form torna nello stato non modificabile.

    I problemi dell'accesso concorrente sono risolti con una scommessa. Al momento di scrivere su server si controlla che qualcuno non abbia modificato dopo il nostro EDIT (tramite un campo DATETIME che ogni record possiede). In questo caso l'utente viene avvertito e perde le sue modifiche, che eventualmente deve ripetere. Per il tipo di applicazione, questi conflitti sono piuttosto rari, e nessuno si è mai lamentato (funziona così anche nella vecchia configurazione solo Access). Il vantaggio è che non è necessario alcun blocco del record mentre l'utente ci sta lavorando.

    Su MySql non è impostata nessuna connessione tra tabelle, tipo testata e dettagli, che, per una mia precedente esperienza di interfacciamento con SqlServer è più fonte di guai che di aiuto. La fase di scrittura su server è naturalmente sotto transazione, il che evita disallineamenti. Nel caso della form sottostante, ad esempio, si può notare in basso una subform di dettagli. In fase di scrittura su server a tasto SAVE dentro la transazione si scrivono sia la testata che i dettagli, ma questo è ovvio.

    Il problema di cui ho chiesto si manifesta nelle form multiistanza (quella sotto non lo è). Si tratta di form molto più complesse, che è necessario poter aprire in più videate per confronti ecc. Tra l'altro in queste form l'accesso al record da gestire non avviene con lo sheet di destra, come nel caso della tabellina sottostante (i record sono troppi), ma con una serie di combobox. Durante i test ogni tanto, ma anche spesso, queste form si sfasciano, nel senso che non si aprono più, Se si tenta di aprirle tramite un doppio click sul nome rimangono silenti, se si aprono tramite codice VBA danno origine a un errore 2001. Per risolvere il problema o si fa una copia e la si mette al posto dell'originale, oppure si aprono in design (il che è possibile) e da lì si chiede la visualizzazione in formato FORM o SHEET. A quel punto magicamente tornano a posto. 

    Il problema è difficile da individuare, poiché il deterioramento della form si evidenzia solo a una successiva riapertura. Cercherò di capire quale parte del codice VBA che sta sotto la form mette in crisi il repository di Access, togliendolo un po' alla volta. Il che sarà un lavoraccio, poiché, ripeto, il problema sorge ogni tanto. A questo punto vi chiedo: esiste un analizzatore del repository che sia in grado di trovare quale sia il problema della form che non si apre più?

    Edit: avevo messo la picture di una form di esempio che però non si vede. Metto un link al mio drive, spero che si possa

    https://drive.google.com/file/d/1GdZHPLI52TBx01dMX8v6TkxDZZ6PnIrv/view?usp=sharing

    Nel frattempo, come da consiglio, ho reimportato tutti gli oggetti in un accdb nuovo, ma non è servito.

  • Re: Form che si sfasciano

    Quale e' esattamente l'utilita' di avere un db in locale, se poi i “dati veri” sono sul db server esterno?

    Voglio dire, perche' alcune informazioni le memorizzi su tabelle locali solo temporaneamente?

    Non si potevano tenere in ram con delle classi contenenti le variabili che ti servono, senza scomodare un db locale?

    Chiedo ehhh, non dico sia meglio un sistema rispetto ad un altro, vorrei capire come mai e' stata fatta questa scelta

  • Re: Form che si sfasciano

    05/11/2024 - amorosik ha scritto:


    Quale e' esattamente l'utilita' di avere un db in locale, se poi i “dati veri” sono sul db server esterno?

    Voglio dire, perche' alcune informazioni le memorizzi su tabelle locali solo temporaneamente?

    Bella domanda.

    Non si potevano tenere in ram con delle classi contenenti le variabili che ti servono, senza scomodare un db locale?

    Si io ho usato anche questo metodo, va bene solo per le maschere Detail(Singolo record) ma basta lasciare in ReadOnly i dati dal Server…

    Chiedo ehhh, non dico sia meglio un sistema rispetto ad un altro, vorrei capire come mai e' stata fatta questa scelta

    Esistono le TRANSAZIONI anche… Modifica(Begin), confermi(Commit) o annulli(RollBack) tutto standard… nativo… nulla da inventare.

    Temo sia un metodo fondamentalmente usato per emulare le transazioni… ma esistono.

  • Re: Form che si sfasciano

    05/11/2024 - Catafirro ha scritto:


    A destra abbiamo una subform linkata alla tabella reale MySql. Sulla sinistra abbiamo la form principale linkata a una tabella locale access che è l'immagine della stessa tabella MySql. Ad ogni spostamento di record sulla subform a destra corrisponde la lettura del record e il suo inserimento nella tabella locale, che contiene sempre e solo un record (quindi viene eliminato il precedente prima di inserire quello nuovo).

    se un utente ha aggiornato il record tu vedi ancora il vecchio record (lato server) a meno che chi ha modificato il record non manda un messaggio a chi sta visualizzando il record o entra nel client ed effettua un refresh (che dovrebbe includere la riscrittura nella tabella locale).

    05/11/2024 - Catafirro ha scritto:


    I dati non sono modificabili fino a quando non si schiaccia il bottone EDIT del menù Ribbon. Le modifiche avvengono sulla tabella locale. Quando l'utente ha finito schiaccia SAVE e un codice aggiorna il corrispondente record MySql, mentre la form torna nello stato non modificabile.

    anche collegato alla tabella server i dati non si aggiornano finchè non fai il post del record. (bello il termine “schiaccia”). 

    anche schiacciando SAVE chi sta consultando il record non vede le modifiche…

    05/11/2024 - Catafirro ha scritto:


    I problemi dell'accesso concorrente sono risolti con una scommessa. Al momento di scrivere su server si controlla che qualcuno non abbia modificato dopo il nostro EDIT (tramite un campo DATETIME che ogni record possiede). In questo caso l'utente viene avvertito e perde le sue modifiche, che eventualmente deve ripetere.

    prevedo un effetto ping pong tra due utenti… tuttavia, se intendi modificare il record e mysql è impostato come innodb, puoi bloccare il record (alla modifica non alla consultazione) se è impostato come myisam basta che il campo datetime non sia null. se null non permetti l'edit (effettivamente ti bastava un flag). se un utente, dopo aver aggiornato 30 campi si ritrova il messaggio “record in modifica da un altro utente” esclama: x@@@###!!! meglio avvisarlo prima di fargli perdere tempo inutile.

    05/11/2024 - Catafirro ha scritto:


    Su MySql non è impostata nessuna connessione tra tabelle, tipo testata e dettagli, che, per una mia precedente esperienza di interfacciamento con SqlServer è più fonte di guai che di aiuto.

    potrebbe essere colpa tua e non del db?

    05/11/2024 - Catafirro ha scritto:


    Il problema di cui ho chiesto si manifesta nelle form multiistanza (quella sotto non lo è). Si tratta di form molto più complesse, che è necessario poter aprire in più videate per confronti ecc.

    i problemi di cui sopra all'nma potenza…

  • Re: Form che si sfasciano

    Beh ragazzi, non è che posso qui raccontarvi come è fatto il mio software, sarebbe troppo lungo. Dico solo che l'uso di tabelle access locali è di gran lunga più comodo di una lunga sfilza di variabili, sistema che diventa di uso quasi impossibile via via che aumenta il numero dei campi e soprattutto nei casi di varie tabelle di dettaglio. Le variabili locali le uso in form che chiedono informazioni per effettuare operazioni, tipo un filtro per una ricerca  e simili. Ma anche in questo caso si rendono utili le tabelle locali se la ricerca è complessa, e prevede magari tanti valori in AND a loro volta in OR. In questo caso i valori in AND possono essere i campi di una tabella locale,  e i record gli OR. Gestirli nella classica matrice o in una apposita classe di oggetti sarebbe più complesso. Ma è solo un esempio. 

    Riguardo il mio problema, credo di averlo individuato. Si tratta delle form multiistanza, che evidentemente nel nuovo sistema, ma non so per quale motivo, hanno fatto emergere un bug di Access. La gestione è quella normale con una collection, quindi dovrebbero funzionare. E funzionano fino a che l'applicazione rimane aperta. Quando viene chiusa, al momento della riapertura succede che una o più siano “rovinate”. Sto studiando una soluzione di compromesso. Comunque grazie dell'attenzione.

  • Re: Form che si sfasciano

    05/11/2024 - Catafirro ha scritto:


    Beh ragazzi, non è che posso qui raccontarvi come è fatto il mio software, sarebbe troppo lungo. Dico solo che l'uso di tabelle access locali è di gran lunga più comodo di una lunga sfilza di variabili, sistema che diventa di uso quasi impossibile via via che aumenta il numero dei campi e soprattutto nei casi di varie tabelle di dettaglio. Le variabili locali le uso in form che chiedono informazioni per effettuare operazioni, tipo un filtro per una ricerca  e simili. Ma anche in questo caso si rendono utili le tabelle locali se la ricerca è complessa, e prevede magari tanti valori in AND a loro volta in OR. In questo caso i valori in AND possono essere i campi di una tabella locale,  e i record gli OR. Gestirli nella classica matrice o in una apposita classe di oggetti sarebbe più complesso. Ma è solo un esempio. 

    Non credo tu abbia capito benissimo i suggerimenti, o meglio mi sembri chiuso a capire,… nessuno di buona razionalità usa più le variabili locali penso dagli anni 80…!
    Ci sono tecniche decisamente più tecniche, prendono il nome di DAL, Data Access Layer, ovvero si creano interfacce ai dati strutturate, che possono essere realizzate con delle classi specifiche, questo Eventualmente si optasse per questa tecnica.

    Ma in realtà continui a deviare dal vero problema, del perchè hai ritenuto di dover lavorare in questo modo, è una questione di ingegneria del sistema, e clonare le tabelle in locale è sbagliato 

    Importare e duplicare TUTTA la tabella per poi modificare 1 Record è fuori da ogni logica, se un collega nel fratempo ha modificato un record differente dal tuo… tu non sei più sincronizzato, e quando vai a scaricare la tua Tabella locale nel server come BatchUpdate, che controlli fai prima di sovrascrivere i dati che NON HAI MODIFICATO TU, ma magari lo ha fatto un collega…?
    Potrebbe anche avere un senso se tu in LOCALE ti copiassi SOLO il record da editare…, allora la buona tecnica prevede che lato SERVER venga BLOCCATO il record(ecnica da definire, potrebbe bastare un Flag Boolean), e tu nel Client farai in modo che se bloccato resti READONLY, o quando lo hai modificato lo vai a sovrascrivere e liberare, ma solo 1 non tutta la tabella, in questo modo eviti conflitti.

    La gestione MultiUtenza è tuttavia una cosa assai più complicata volendo ben guardare. 

    Conosci le transazioni…? (se la risposta è no, dovresti valutarle bene)

    Riguardo il mio problema, credo di averlo individuato. Si tratta delle form multiistanza, che evidentemente nel nuovo sistema, ma non so per quale motivo, hanno fatto emergere un bug di Access. La gestione è quella normale con una collection, quindi dovrebbero funzionare. E funzionano fino a che l'applicazione rimane aperta. Quando viene chiusa, al momento della riapertura succede che una o più siano “rovinate”. Sto studiando una soluzione di compromesso. Comunque grazie dell'attenzione.

    Mah… penso sia meglio lasciarti procedere.

  • Re: Form che si sfasciano

    05/11/2024 - Catafirro ha scritto:


    Dico solo che l'uso di tabelle access locali è di gran lunga più comodo di una lunga sfilza di variabili, sistema che diventa di uso quasi impossibile vi

    Forse quello che non hai capito tu è che non stai attaccato al server come non stai attaccato al db locale.

    Il componente dataset fa quello che stai facendo tu: chiede al server i dati, il server li invia alla macchina e il componente te li fa vedere. Tu stai moltiplicando per 2 quello che fa access solo che access non si confonde.

    Poi fai come credi…

  • Re: Form che si sfasciano

    Dunque, ero entrato qui per chiedere aiuto e mi vedo sottoposto a giudizio. So bene cosa sono le transazioni, mi sono laureato in informatica quando molti di voi ancora dovevano nascere, nel 1978. Certo, questo mondo è in continua evoluzione, e stargli dietro non è facile, quindi mi potrebbe essere sfuggita qualche nuova tecnica da usare con Access. In ogni caso la mia soluzione per la multiconcorrenza probabilmente non l'avete capita. L'uso delle tabelle locali access è una questione di comodità e di semplicità. Visto che ci sono le uso, senza costruire strutture alternative che peraltro VBA non aiuta a gestire. Usandole posso usufruire di tutti gli strumenti access, dall'uso dei recordset DAO nel codice all'esame del contenuto del record durante i debug.

    Ripeto la mia gestione della multiconcorrenza, intendendo per multiconcorrenza l'accesso IN MODIFICA allo stesso record tramite form. Per lo stesso record intendo la testata con eventuali dettagli. Sia la tabella MySql sia la sua immagine access sono dotate di un campo DATETIME che viene riscritto ad ogni update. Quando l'utente vuole modificare un record il programma legge attraverso un recordset ADO e memorizza nella tabella locale i dati a quel momento, compreso il DATETIME. Quando l'utente ha fatto le sue modifiche e ha chiesto il salvataggio, dopo magari aver bevuto un bel caffè per tenersi su di morale, il programma rilegge il record da server, e se trova il DATETIME cambiato avverte che non è possibile salvare, ma che la modifica va ripetuta. Quante volte in 25 anni di funzionamento è successa una cosa del genere? Sono ancora vivo, per cui tanto spesso non credo. Il vantaggio naturalmente è che non si tiene bloccato il record a lungo, che, ripeto, potrebbe essere davvero a lungo visto che l'utente è una variabile indipendente e non prevedibile. Il blocco di un record è sempre un'operazione delicata, che può interferire con le transazioni, quindi per mia esperienza personale evito il più possibile, se riesco a gestire i dati in modo diverso. All'atto pratico la procedura che sto convertendo con interfaccia MySql ha funzionato per 25 anni interfacciata con un db access, non proprio il massimo in termini di affidabilità, con anche una quindicina di utenti in contemporanea e archivi di qualche centinaio di migliaia di record.

    Comunque non è mia intenzione fare polemica, anche se devo riconoscere che mi aspettavo un'accoglienza più amichevole, un aiuto, ma non importa. In realtà avevo dimenticato che i forum sono così. Magari riproverò più avanti per un eventuale nuovo problema, dopo aver risolto questo, e magari non inerente Access. 

Devi accedere o registrarti per scrivere nel forum
22 risposte