Date instabili nelle Tabelle (quella giusta è 11/06/1966)

[charlie]

p.s.
sul forum inglese hanno attivo il controllo dei messaggi

È una misura antispam valida per i nuovi iscritti, ma presuppone che un amministratore/moderatore se ne prenda carico.

[unlucky83]

ah ecco..sono iscritto dal 2016 ma non ho postato mai nulla

[oquintoo]

Grazie unlucky83 per l'informazione, e grazie per il supporto oltremanica

[unlucky83]

Ma i sistemi Linux che usi sono tutti a 64 bit oppure a 32?
Nei record incriminati la data retrocede “ci” retrocede di un’ora aprendo il db in windows, e noi ci troviamo nella time zone UTC +1
Ora io uso Ubuntu a 32 bit e secondo me è la versione a 32 bit di libreoffice che presenta il bug

[oquintoo]

Il file Base l'ho creato due anni e mezzo fa , su Ubuntu 16.04 a 32 bit con LibreOffice preinstallato ( quello originale di ubuntu), su un sistema in dual boot con Windows7Pro a 32 bit ( ho mantenuto windows a 32 bit perchè posseggo vecchie schede sia audio che d'acquisizione video e TV che non supportano i 64 bit,....finchè durano l'adopero...).
Dopo un anno mi sono accorto del problema e feci un post sul forum di Ubuntu, ....praticamente ignorato...
Per quanto riguarda

secondo me è la versione a 32 bit di libreoffice che presenta il bug

io non penso...., dico questo perchè è da Novembre che uso Manjaro o Debian a 64 bit con il relativo software a 64 bit, è però vero che windows è sempre lo stesso a 32 bit......quindi tutto può essere

Leggendo il bug inglese ......non risolto peraltro....dove un utente lamentava il fatto che ha dovuto riscrivere centinaia di date, penso che il problema sia più legato ,...o a Java, oppure al motore HSQLDB.

Ovviamente siamo in campo di ipotesi ed io non ho le competenze per discriminare l'errore, comunque è dovuto da un "interprete" e non dal supporto fisico sia essa una usb o hardisk,
quindi al momento escluderei sistema operativo e supporti difettosi, sapessi dove vengono scritti i dati e come vengono letti , sarei vicino alla soluzione

[unlucky83]

se cambi l’estensione del file in zip e poi lo decomprimi, trovi tutto il progetto del db è un file chiamato data che è la raccolta dei dati. L’ho aperto con un editor binario di Linux ma il campo Data è un ammasso di bit che rappresentano di per se caratteri non stampabili. Non credo che così risolvi. L’interprete Java è differente su 32 bit e 64 bit.
Io lavoro su win 64 bit e ubuntu 32 bit, questa al momento é l’unica cosa che ci accomuna..ovvero che passiamo da un’architettura ad un’altra.
Farò altre prove, casomai provo in questi giorni qualche live di ubuntu a 64 bit

[unlucky83]

Aggiungo che se il bug riguarda la time zone + formato data GG/MM/AAAA, difficilmente sul forum inglese troveremo qualcun’altro che riscontri un comportamento anomalo. È più facile trovarli nel forum tedesco

[charlie]

oppure al motore HSQLDB

La versione incorporata in Base è la 1.8.x, volendo potresti provare a passare alla 2.4.0. Sul forum trovi come fare.

[oquintoo]

@ unlucky83
per quello che riguarda

Io lavoro su win 64 bit e ubuntu 32 bit, questa al momento é l’unica cosa che ci accomuna..ovvero che passiamo da un’architettura ad un’altra.

appena posso in settimana, provo ad installare un sistema linux a 64 bit sul PC di un'altro mio figlio che ha Win7Pro a 64bit (se mi da il permesso ...)

@ charlie

Non ho mai aggiornato il motore HSQLDB, comunque se l'operazione è alla mia portata proverò

[oquintoo]

Sono andato sul PC di mio figlio che ha Windows 8 a 64 bit per fare la prova che avevo descritto a unlucky83 , ho scaricato il file dal forum, l'ho aperto con LibreOffice (c'era questo già installato) e la data mostrata è 10/06/1966,sicuro di avere inviato la data 11/06/1966 sono andato sul mio con Manjaro, ho riscaricato lo stesso file e quando l'ho aperto ha mostrato la data 11/06/1966 ( che è quella originale del file che ho inviato).

Forse è il caso di scrivere che il dato corretto è 11/06/1966 e tutti coloro che hanno visualizzato 10/06/1966 hanno letto un dato errato, non conforme a quello inviato...., e se fosse capitato a qualcuno, di avere il file con la data 10/06/1966 , sarebbe utile che lo comunicasse per poter discriminare l'errore.....

[oquintoo]

@ unlucky83

Io lavoro su win 64 bit e ubuntu 32 bit, questa al momento é l’unica cosa che ci accomuna..ovvero che passiamo da un’architettura ad un’altra

Aggiorno la situazione, si può escludere il problema dei sistemi 32 o 64 bit,
Ho installato Manjaro 64 bit sul PC di mio figlio che ha anche WIN8 64 bit, e dopo aver scaricato il file dal Forum su Manjaro ho visualizzato la data corretta 11/06/1966 poi ho riavviato e riaperto su WIN8 lo stesso file ed ho visualizzato la data 10/06/1966, quindi come sospettati rimangono Java e il motore HSQLDB.

La cosa interessante, come ho già scritto , che se scarico il file su un sistema windows visualizzo la data 10/06/1966, se lo scarico usando un sistema liunx visualizzo la data (corretta) 11/06/1966

[unlucky83]

Questo perchè da windows va a togliere un'ora al valore data, rendendo il valore data decimale, poi lo tronca ad intero ed ecco che ha scalato un giorno. Questo perchè hai caricato il file con i dati inseriti quando stavi lavorando su Linux. Quando scarichi il file su un sistema linux, va ad interpretare correttamente la data.
Cosa succede dopo essere passati da windows a linux? Succede che in linux va ad aggiungere un'ora al valore data, rendendolo decimale, lo tronca poi per difetto e siccome un'ora non fa aumentare di un giorno, ti rimane la stessa data che hai visualizzato in windows.
Non è un problema del record, perchè ho aggiunto campi alla tabella per verificare questa cosa, ho inserito più date per lo stesso record e il problema lo da con 11/06/1966 ma non con 6/11/1966. Ovvero con una data del tipo 6/11/1966 non si verifica il giochetto della perdita e dell'aggiunta di un'ora. Ho il sospetto che il problema della corretta interpretazione della timezone stia nelle date con i mesi da 01 a 09.Devo condurre altre prove ma è pesante riavviare continuamente il pc per cambiare sistema operativo hehehe

Domanda: io ho condotto prove solo sul mio pc che ha il dualboot. Tutte le tue prove sono state fatte su pc che hanno il dualboot oppure hai provato anche su pc che hanno un solo sistema operativo presente?

[oquintoo]

Bisognerebbe verificare da un sistema windows non in dualboot che data visualizza , stasera provo dal portatile di mia moglie ( non c'avevo pensato), ...comunque rimane il fatto che le date, a distanza di un anno , cambiano tutte......

[oquintoo]

Ho provato dal PC di un'altro mio figlio che ha solo Win7Pro64bit aggiornato su un processore diverso (AMD FX 8core) con SSD , quindi diversissimo dal mio.....sono andato nel forum , ho scaricato il file e ho visualizzato la data sbagliata 10/06/1966, proprio quello che succedeva quando davo il database su una chiavetta per leggerlo su un sistema windows.......

Tra l'altro ho verificato che Calc non adopera Java invece Base si perchè ho provato su un sistema senza java e Calc funziona mentre invece Base da errore ( sul sistema non è presente JRE runtime Java, ..una cosa del genere)

[unlucky83]

Ok bene, il cerchio si stringe.
Charlie visto che hai provato il file, tu che data visualizzi?

[unlucky83]

Ho provato vari formati date...al momento l'unico formato date che mi sembra mantenere le date invariate è MM/DD/YYYY impostando la lingua Inglese(USA). A breve allego file di test

[charlie]

Charlie visto che hai provato il file, tu che data visualizzi?

11/06/66.

[oquintoo]

Stavo cercando di cambiare HSQLDB 1.8 con quello più aggiornato ma al momento non ho capito se lo devo installare oppure avviarlo con uno script, ma prescindere da questo, ammesso e non concesso che io abbia HSQLDB aggiornato, quando un'altro utente apre il file Base, comunque si ritrova ad avere quello preinstallato nel suo software , che è l' 1.8
La mia è solo una perplessità, anche perché ammetto di non riuscire ad installare HSQLDB versione 2.4 per fare il test...

[charlie]

Le 2 versioni di HSQLDB non sono compatibili fra loro, pertanto ti possono creare problemi di portabilità.
Puoi evitare l'installazione utilizzando un'apposita macro che trovi su questo forum ma più in dettaglio su quello inglese.
Tieni presente che in questo modo i file sono molto pesanti.

[oquintoo]

Grazie per l'informazione,... altrimenti c'avrei messo un sacco di tempo per capirlo..
Ammetto di non essere in grado di capire il perchè accada una cosa del genere, rimane il fatto che se si rimane sullo stesso sistema operativo i dati rimangono stabili, eventualmente è meglio esportarli su Calc ( che non soffre di questo problema) e condividere con qualsiasi sistema operativo

[unlucky83]

Dopo aver fatto tutte le prove possibili cambiando il formato delle date, la timezone del sistema operativo, impostato l'ora da RTC a UTC e viceversa, cambiato le opzioni di Escapedatetime etc... non ho concluso nulla.
Quindi ho provato la strada del DB che utilizza un hsqldb esterno (versione 2.3.2) e con grande soddisfazione posso affermare che le date non cambiano più cambiando sistema operativo.
Ho seguito questo link
viewtopic.php?f=13&t=7244&p=38278&hilit ... rno#p38222

Il test l'ho condotto sulle date a partire dal 1/1/1900 fino al 31/12/2019 e non ne ha cambiata nessuna

[oquintoo]

@unlucky83
Bè , per prima cosa ti devo ringraziare per il tempo che c'hai perso, i sospetti erano finiti su Java e il motore HSQLDB e già charlie consigliava di usare la versione 2.4, ....
però, ....
come diceva Lubrano (altri tempi) ...La domanda nasce spontanea.... perchè non cambiano versione del motore HSQLDB dato che pare migliore?..

Però, la mia perplessità rimane in piedi

ammesso e non concesso che io abbia HSQLDB aggiornato, quando un'altro utente apre il file Base, comunque si ritrova ad avere quello preinstallato nel suo software , che è l' 1.8
La mia è solo una perplessità

..il problema rimane se sposto il file su altri PC, a meno che faccio fare la stessa procedura di "aggiornamento" (passami il termine) quindi , così com'è il file è bene tenerlo sul proprio PC

Domenica ho aggiornato le date e ho scoperto che oltre alle date sbagliate che avevi trovato c'era tutte le date "invecchiate di tre giorni a parte due date che erano invecchiate di due giorni, invece quelle tra il 66 e il 76 erano "sballate" anche di un mese....quando non c'è una logica matematica è dura trovare il bandolo della matassa

Appena posso farò la prova

[unlucky83]

La portabilità è garantita perchè ti porti a spasso anche hsqlb 2.3
COn il file suggerito da charlie non c'è bisogno di istallare nulla...io semplicemente mi sono portato sulla chiavetta tutto quanto, ma entrambi i Libreoffice hanno ancora la versione 1.8

[oquintoo]

Purtroppo non posso confermare,
ho scaricato il file , eseguito quello che è indicato nella guida

Impostate a Medio il livello di sicurezza delle macro di Open Office (o di Libre Office).
Rimuovete eventuali Class path aggiunte manualmente in Strumenti > Opzioni > OpenOffice > Java (Avanzate in Libre Office)
Scaricare questo file http://www.mediafire.com/download/p2v44 ... rd_v3d.odb e posizionatelo in una nuova cartella del computer.
Fate doppio clic sul file .odb scaricato, abilitate le macro quando vi viene richiesto e rispondete OK nelle successive due finestre di dialogo.

..quindi ho aperto prima testing with hsqldb 2.3.2.odb, attivato le macro , aperto il file base_con_errore.odb su Manjaro ed avevo la data 09/06/66,.....
adesso sono sotto windows7, ho rifatto la stessa procedura ed ho visualizzato la data 08/06/66.....quindi invecchiata...

[charlie]

La procedura che hai riportato serve ad aprire un nuovo file. Hai poi portato al suo interno il vecchio database?
Se non ricordo male bisogna seguire un'altra procedura, trovabile sul forum inglese.

[oquintoo]

Io ho aperto " testing with hsqldb 2.3.2.odb", sono andato su apri file e quindi ho aperto " base_con_errore_data.odb", ho eseguito il test che ha indicato unlucky83 .

Al momento posso assicurare che questa procedura è ininfluente , ho provato anche a scaricare nuovamente dal forum il file e quando lo apro su windows la data visualizzata è 10/06/66( ovviamente sbagliata).

Se trovo quest'altra procedura la proverò......forse si dovrebbe creare un nuovo database e in fase di creazione importare il file.....lo buttata lì, non saprei,

Però se fosse così non è molto semplice per l'utente ordinario ( un clik, massimo due e via...)

[unlucky83]

Alt c’è stato un fraintendimento.
Al link che ho suggerito è possibile scaricare un file odb che usa hsqldb 2.3.2. La prova che ho fatto io è stata:
Aprire il suddetto file dopo averlo scaricato
Aver importato la tabella contenente le date che avevo preparato (tutte dal 1900 al 2019)
Salvato, chiuso.
Poi traferito su chiavetta sia il nuovo db sia la cartella driver sia database.

[charlie]

La versione HSQLDB caricata compare nel bordo inferiore della finestra.

[oquintoo]

@ unlucky83

OK, quindi importando una tabella exnovo sul file ,.. io invece ho aperto il vecchio file, ...in teoria dovrei riscriverlo d'accapo, a parte l'esportazione e l'importazione delle tabelle dovrei ricreare le relazioni, senza tener conto che le chiavi primarie del nuovo database sarebbero diverse....quindi dovrei riassegnare i valori delle persone ,indirizzi, e tutto il resto,....per conto mio non è pensabile, tanto vale ricostruirlo da un'altra parte.
Comunque quando ho un attimo di tempo farò il test

Ti ringrazio per il tempo che ci dedichi, quando posso faccio la mia parte

[unlucky83]

Purtroppo ti ho scritto che il test da me condotto conferma che il problema è localizzato su hsqldb 1.8, ma oltre a questo non ti ho proposto una soluzione.
Per quanto ne sò non è possibile modificare il tuo db impostando direttamente un hsqldb esterno. Questo risolverebbe tutto.
Quindi al momento, quel file dovresti utilizzarlo per creare un nuovo db ex novo. La buona notizia è che non sò molto di base, ma mi sono impegnato per chiarire dove fosse il problema dato che sono riuscito a replicare l’errore.
Charlie di sicuro sa spiegarti per bene che alternative hai a questo punto.

p.s.
Da inesperto opterei per modificare il campo data in campo testo, poi manterrei i formulari con la casella di controllo data per l’inserimento, che però mediante macro convertano il dato in testo così da salvarlo nella tabella. Di sicuro modifiche del genere comportano altre piccole modifiche come per esempio riadattare query e chissà quante altre cose