Formulario: errore "SfxBaseModel::loadFromStorage"

[markinson]

Salve a tutti!
Di nuovo qui con un (mio) problema, per cui purtroppo non riuscirò ad essere preciso nella descrizione del fenomeno che ha causato l'errore. Lo ammetto sin dall'inizio. Infatti, al momento del verificarsi dell'inconveniente, non ho avuto la freddezza di realizzare una screenshot del primigenio messaggio di errore.

Concluse le premesse, passo al dunque.
Ho realizzato una base di dati con AOO versione 4.1.7 su base HSQLDB (si dirà così ... ) e già tre volte mi è capitato che, avendo un formulario aperto, all'improvviso i valori da me introdotti/modificati non vengano accettati, per impossibilità di eseguire l'update dei dati in tabella (sto andando a memoria degli errori di cui non ho eseguito le screenshot sopra accennate).
Tale inconveniente è occorso con formulari differenti.
Puntualizzo, per tentare di offrire un quadro generale, che la base di dati si trova in una cartella di Dropbox, soggetta quindi a sincronizzazione.

Ebbene, verificatasi l'impossibilità di salvare i dati in tabella (su cui stavo interagendo attraverso un formulario ad hoc), chiusa la base di dati (senza poter salvare nulla) e riaperto il dbase, quel determinato formulario si è rivelato inutilizzabile. Non è possibile nemmeno a rinominarlo!

Tentando di aprire il formulario, gli errori che ottengo sono:

(1) in AOO versione 4.1.7

ErroreAperturaFormulario_001.jpg (7.29 KiB) Visto 4638 volte

(2) in LO versione 6.4.5.2 (x64)

ErroreAperturaFormulario_000.jpg (10.38 KiB) Visto 4638 volte

In quest'ultima circostanza, devo aggiungere che il codice dopo "SfxBaseModel::loadFromStorage" muta pressoché ogni volta io tenti di aprire il formulario.

L'unica cosa che sono riuscito a fare è stata quella di cancellare il formulario incriminato e copiare dentro la base di dati lo stesso formulario presente in uno dei miei backup. Agendo così sono tornato in possesso dell'interfaccia (il formulario) che mi permette di operare sulla tabella in maniera più amichevole.

Ora, siccome sono già tre volte che all'improvviso subisco questo evento, chiedo se anche ad altri è capitata la medesima esperienza e se vi sono possibili rimedi per prevenire tali situazioni.

Grazie, come sempre, per l'attenzione.

--- EDIT ---
Ho preventivamente cercato nel forum e rintracciato il thread "errore di scrittura dei dati nel database".
Si avvicina, ma non chiarisce i miei dubbi.

[charlie]

Caro amico, oramai dovresti aver compreso che per avere risposte occorrono i fatti.
Intendo dire il database.

Se stai ancora costruendo il tuo database, due considerazioni generali:

• Adopera dati fittizi per poterlo facilmente condividere sul forum
• Prima finiscilo e poi penserai a gestirlo su dropbox

[markinson]

Caro amico, oramai dovresti aver compreso che per avere risposte occorrono i fatti.
Intendo dire il database.

Hai perfettamente ragione e ne sono consapevole.
Il mio intento era piuttosto quello di sapere se altri erano incappati in errori simili o tal quali a "Non è stato possibile aprire il documento 'nomedocumento'.".
Posso comprendere che questa mia intenzione, in sé, sia sciocca o inutile ai fini della risoluzione del problema a monte; tuttavia, mi spiego, scopo di fondo era capire se altri si erano imbattuti in simili messaggi e con quale frequenza, persino per escludere che potesse essere un inconveniente del mio dbase, ma un male comune più diffuso.

Se stai ancora costruendo il tuo database, due considerazioni generali:

• Adopera dati fittizi per poterlo facilmente condividere sul forum
• Prima finiscilo e poi penserai a gestirlo su dropbox

In realtà il dbase nelle sue strutture portanti, tabelle e relazioni intendo, è finito e già abbastanza popolato, sempre fatto salvo l'insorgere di nuove esigenze.
Sulla base di dati vi lavoro esclusivamente io, però si trova in una cartella di Dropbox per avere la comodità di potervi accedere da qualunque mia postazione informatica con facilità.

Concludo aggiungendo, semmai occorresse, che l'inconveniente è capitato avendo più formulari contemporaneamente aperti e aperti da diverse ore.

Grazie per l'attenzione!

[Zago_87]

Ciao, in tanti anni di utilizzo no, mai capitata una cosa del genere, devo però precisare che non tengo mai un DB aperto per molte ore sullo stesso formulario.
A breve farò dei test di utilizzo su DropBox ma userò una versione splittata, ti farò sapere se mi troverò nella tua situazione ma credo (per via dello split) e spero di no

Ma il problema quando non usavi DropBox non si era mai presentato ed è comparso solo dopo lo spostamento?

Provando a fare delle ipotesi:
Può essere che la postazione abbia perso la connessione internet (o magari tu eri connesso ma era il server di DropBox ha avuto un momento di crisi)? Puoi simularlo molto facilmente scollegando la rete con il formulario aperto per un tot di tempo, per poi riconnetterti e vedere che succede. Potresti anche provare a scollegare la rete solo in fase di salvataggio dei dati. In definitiva simuleresti un problema di connessione o sincronizzazione e così spero ti toglieresti un dubbio.

Per quanto hai trovato sull'altro post si trattava di un bug che credo sia stato risolto, hai comunque aggiornato recentemente il AOO?

[markinson]

Ciao, in tanti anni di utilizzo no, mai capitata una cosa del genere, devo però precisare che non tengo mai un DB aperto per molte ore sullo stesso formulario.

Mai dire mai!
Scherzo! Spero che l'inconveniente non ti capiti, ci mancherebbe!

Ma il problema quando non usavi DropBox non si era mai presentato ed è comparso solo dopo lo spostamento?

Il database è nato e cresciuto dentro una cartella di Dropbox. Da lì non si è mai mosso, ecco.

Provando a fare delle ipotesi:
Può essere che la postazione abbia perso la connessione internet (o magari tu eri connesso ma era il server di DropBox ha avuto un momento di crisi)? Puoi simularlo molto facilmente scollegando la rete con il formulario aperto per un tot di tempo, per poi riconnetterti e vedere che succede. Potresti anche provare a scollegare la rete solo in fase di salvataggio dei dati. In definitiva simuleresti un problema di connessione o sincronizzazione e così spero ti toglieresti un dubbio.

E' esattamente ciò che ho pensato pure io! Per questo ho precisato che il dbase si trova in una cartella di Dropbox. Non avevo però fatto il passo in più che invece hai saputo compiere tu, ossia quello di pensare di andare a simulare una, più o meno breve, disconnessione. Lo farò quanto prima e riferirò!

Per quanto hai trovato sull'altro post si trattava di un bug che credo sia stato risolto, hai comunque aggiornato recentemente il AOO?

Perdonami, ma non ho capito.
Dici il bug sulla query?

Grazie per il supporto!

[markinson]

Un piccolo aggiornamento sulle prove eseguite che, anticipo subito, non sono riuscite a riprodurre l'errore, come invece sperato.

Ho aperto un database esistente in una cartella di Dropbox e iniziato ad aggiungere/modificare record, attraverso un apposito formulario.
Quindi ho staccato la connessione, prima per un breve periodo, poi sino ad ottenere l'opacizzazione dell'icona di Dropbox (a significare in quest'ultimo caso che la connessione doveva essere ripresa da zero).
Durante il periodo di disconnessione, ho continuato la manipolazione della base di dati, sempre attraverso lo stesso formulario.
Ristabilita la connessione, ho proseguito a interagire con il database, senza tuttavia che nulla di strano accadesse.

Eppure, resto convinto che, in qualche modo, è come se l'interfaccia offerta dal formulario si disallineasse con la base, ossia con il cuore che è la tabella e questo distacco/scollamento finisca per provocare l'errore che ho fotografato.

In rete ho trovato la discussione "Error message "Sfx BaseModel::load From Storage: Oxf26" when trying to open forms"; ad ogni modo sembra che il problema sia stato risolto: "Bug 89982 - FILEOPEN Can't open particular base form (SfxBaseModel::loadFromStorage:0xf26)".

[markinson]

Ho eseguito qualche ulteriore prova e, sperando di fare cosa utile, riporto il percorso svolto.
Anticipo solo, per non far perdere tempo a nessuno, che le numerose peripezie descritte non hanno condotto da nessuna parte (se non forse a escludere qualche opzione, forse).

Sono prioritariamente partito dal bug 89982, qui: Bug 89982 - FILEOPEN Can't open particular base form (SfxBaseModel::loadFromStorage:0xf26)

Lo stato di questo bug è: RESOLVED WORKSFORME

Che significherà "WORKSFORME", mi sono chiesto.
Questo: "The problem used to be reproducible, but it is not anymore with the latest version of LibreOffice. Unlike FIXED, exact fix commit is not known."
Benedicendo il traduttore di Google: "Il problema era riproducibile, ma non è più [presente] con l'ultima versione di LibreOffice. A differenza di CORRETTO, il [confinamento] esatto della correzione non è noto."

WORKSFORME diventa insomma più chiaro se scritto: WorksForMe (cioè: per me funziona).

Nell'ultimo intervento relativo al bug sopra citato si diceva:

I don't know if if you reproduced again the behaviour but just 2 simple things to do (perhaps you already did it).
1) Upgrade to a newer LO version
2) Make a backup, rename your file in zip file and check if the zip extract is ok.

Quindi, avendo già l'ultima versione di LO, ho preso il mio dbase corrotto e l'ho rinominato come nomefile.zip.
Ho fatto eseguire al programma di compressione una verifica dell'archivio e risulta che:

Allora sono andato alla ricerca, dentro alle varie cartelle e attraverso l'esploratore del mio programma di compressione, del file corrotto e ho scoperto che la dimensione dello stesso, non compressa, è pari a una cinquantina di KB.

Questa è la maschera-formulario che non si apre più!

Estratto puramente e semplicemente l'archivio (compresso), il file corrotto, relativo alla maschera-formulario, assume un peso di 0 KB (anziché i 50 KB e più sopradetti):

La mia attenzione si è spostata pertanto sulla riparazione del file compresso e corrotto.
Ho eseguito le operazioni per tentare il ripristino con il programma (gratuito) DiskInternals ZIP Repair (nella versione portable).
Terminate, con successo, le operazioni di (tentato) ripristino, ho di nuovo cambiato l'estensione da ".zip" a ".odb", ma la maschera-formulario è sempre risultata irrimediabilmente corrotta.

Finale: form corrotto ed errore che non sono riuscito a riprodurre.

[markinson]

Ancora cerca che ti ricerca:
Bug 131267 - error that disappears some forms that I have made

[markinson]

Oggi si è verificato di nuovo l'errore che, in genere, porta alla distruzione di qualche form del dbase.
Questo:

Se non ricordo male, tra le vicissitudine odierne, stavolta, meglio di tutte le altre, è andata in malora l'intera base di dati.
Del menzionato file ".log" nessuna traccia dentro la cartella (prima di dare "Ok" ho verificato).

[markinson]

Il fenomeno si è ripresentato di nuovo.
Come in genere accade, si è annunciato con un drastico rallentamento nelle operazioni di lettura/scrittura sulla base di dati.

Stavolta ho cliccato sul pulsante "Extra" e il risultato è quello indicato nella screenshot a seguire.

Oltre alle ripercussioni sulla base di dati (in genere vengono corrotti i formulari), mi resta il cruccio di capire se la genesi è endogena, cioè è colpa di come ho progettato il dbase, oppure vi sono fattori esogeni che, ahimè, non posso controllare.

Grazie ancora per l'attenzione.

[Zago_87]

Ciao di nuovo, per la mia esperienza posso dirti che si, come è stato progettato il DB e come sono state scritte le righe di codice influisce drasticamente sulla stabilità. La prima versione del mio DB dava abbastanza spesso errori, ad un certo punto ho ricominciato tutto da capo, passando da AOO a LO, riscritto tutto facendo tesoro della prima esperienza e delle info ricavate da questo e da altri forum. Risultato, praticamente azzerati gli errori e i problemi come quello che descrivi qui.

Da qui a dirti che la causa è come hai strutturato il DB...beh è lunga, soprattutto senza poter vedere il file e senza sapere come hai ragionato per costruirlo.

Parli di un rallentamento prima del blocco, cosa che accadeva anche a me, se monitori le prestazioni del PC nel momento in cui rallenta tutto cosa vedi? CPU prossima o al 100%? RAM completamente occupata? Quali operazioni esegui prima del blocco? Sei nello stesso formulario e fai inserimenti multipli o ti sposti tra diversi formulari/rapporti e fai cose differenti? Puoi testare per qualche giorno il DB in locale senza tenerlo su DropBox?

[markinson]

Ciao Zago_87!
Prima di ogni cosa, grazie davvero per il tuo tempo, il supporto/sopporto (!) e la partecipazione alle mie disavventure informatiche.

Riprendo il tuo intervento per stralci, così da confrontarci sui tuoi suggerimenti.

Ciao di nuovo, per la mia esperienza posso dirti che si, come è stato progettato il DB e come sono state scritte le righe di codice influisce drasticamente sulla stabilità.

Il mio povero dbase è fatto, in sostanza, solo di tabelle e formulari, senza alcuna riga di codice, che non saprei proprio scrivere.
Anche nel mio caso tutto è nato con AOO, ma sto ben pensando di passare mani e piedi a LO, versione "still".

... se monitori le prestazioni del PC nel momento in cui rallenta tutto cosa vedi? CPU prossima o al 100%? RAM completamente occupata?

In realtà l'elaboratore continua ad andare tranquillamente. Il rallentamento interessa soltanto la gestione della base di dati.

Quali operazioni esegui prima del blocco? Sei nello stesso formulario e fai inserimenti multipli o ti sposti tra diversi formulari/rapporti e fai cose differenti?

In realtà il rallentamento capita all'improvviso, durante la fase di inserimento.
Mi spiego meglio. Tale rallentamento occorre soltanto con le maschere e, almeno sinora, non mi è mai successo accedendo direttamente alla tabella dei dati (adesso sono a oltre mille record, con circa 20 campi per record).
Il rallentamento, inoltre, può colpire (e colpisce) indistintamente una maschera (che a dire il vero ha diversi subform) piuttosto che un'altra e persino se questa ha una semplice forma tabellare.

Puoi testare per qualche giorno il DB in locale senza tenerlo su DropBox?

Proverò questa strada, anche se le prove di disconnessione già fatte non hanno forzato la generazione degli errori di lettura/scrittura sopra riferiti.

GRAZIE!

[charlie]

adesso sono a oltre mille record, con circa 20 campi per record

In un cassetto della mia memoria, di cui ho smarrito la chiave di accesso , c'è il ricordo di qualcuno che sconsigliava l'uso di HSQLDB 1.8 per database con molti record, perché non adatto. Chiaramente la prima conseguenza possibile è un rallentamento.

Comincia a prendere in considerazione, se la mi ipotesi fosse azzeccata, l'eventualità di migrare il tuo database su altro motore (es. MySql) pur conservando Base come interfaccia.

Inoltre, sarebbe buona norma eseguire periodicamente operazioni di manutenzione: https://wiki.documentfoundation.org/ima ... eGuide.pdf pag. 423.

[markinson]

Grazie anche a te charlie per i suggerimenti!

... qualcuno che sconsigliava l'uso di HSQLDB 1.8 per database con molti record, perché non adatto.

Veramente credevo che il mio database fosse piccolo, limitandomi - ammetto - a controllare il peso in KB dello stesso (poche centinaia).

Chiaramente la prima conseguenza possibile è un rallentamento.

Il rallentamento improvviso, prima dell'errore, si è purtroppo manifestato sin dall'origine, ossia prima che raggiungessi quota mille record.

Comincia a prendere in considerazione, se la mi ipotesi fosse azzeccata, l'eventualità di migrare il tuo database su altro motore (es. MySql) pur conservando Base come interfaccia.

Questa è un'altra bellissima sfida. Almeno potrei mettere a frutto la piccola guida di MySQL che ho acquistato tempo addietro.

Inoltre, sarebbe buona norma eseguire periodicamente operazioni di manutenzione: https://wiki.documentfoundation.org/ima ... eGuide.pdf pag. 423.

Grazie ancora! Nonostante il mio arrugginito inglese, cercherò di cavarmela in qualche maniera.

[Zago_87]

In un cassetto della mia memoria, di cui ho smarrito la chiave di accesso , c'è il ricordo di qualcuno che sconsigliava l'uso di HSQLDB 1.8 per database con molti record, perché non adatto. Chiaramente la prima conseguenza possibile è un rallentamento.

Nella mia pur breve memoria ho lo stesso ricordo, devo però dire che ho un DB con migliaia e migliaia di record in tabelle con anche 30/40 colonne come minimo...non ho questo tipo di problemi pur avendo tanti dati, tantissime righe di codice tra macro e SQL per le query, viste, genero report complessi, PDF, ecc. Insomma un uso abbastanza completo delle funzionalità.

Certo come segnalato in altre discussioni sto passando a una versione split per tentare di risolvere alcune problematiche e per prevenire il raggiungimento del "limite" di HSQLDB 1.8 però ecco, da quel che riferisce Markinson, non credo sia un problema di quantità di dati.

Di certo però non smentisco Charlie, passare al motore MySQL è sicuramente un upgrade, se te la senti poi ci farai avere la tua esperienza che sarà molto utile

PS: se hai intenzione di ripartire da zero su LO a questo punto valuta di splittare il DB, credo sia una buona occasione

[markinson]

Grazie ancora a entrambi per i suggerimenti!

Le strade che si propongono sono sostanzialmente tre:

• intanto passare a LO (o reimpostare tutto in LO);
• splittare/dividere il dbase (magari quando sarà più corposo; intanto provvederò a manutenerlo come suggerito da charlie);
• appoggiarmi a MySQL.

La prima è la soluzione, ovviamente, più indolore. Innanzitutto, però, vorrei ampliare e poi consolidare le mie conoscenze di Base, anche in termini di scrittura di (piccole) righe di codice. Tanto più che la frequenza con cui incappo in errori mi aiuta a dover ogni volta tentare di trovare una scappatoia e, in questo modo, apprendo.

Grazie e alla prossima!