Usare HSQLDB 2.3.2 senza installarlo

[charlie]

La pubblicazione di questo argomento è stata autorizzata da DACM, autore di questo post sul forum inglese: https://forum.openoffice.org/en/forum/v ... 83&t=61183.

Utilizzatori di Base, avete mai desiderato usufruire di qualche funzione che nel database incorporato (HSQLDB 1.8) non è disponibile?
Facendo una ricerca avete visto quello che vi serviva nella versione 2.3.2 di HSQLDB ma non lo volete installare?
Quanto segue fa al caso vostro, basta seguire queste poche istruzioni:

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

Vi troverete all'interno di un nuovo database dove poter fare tutte le esperienze con il nuovo motore.

[charlie]

Riporto un esempio di una funzione, non disponibile nella versione incorporata, molto utile: DATEADD.
Serve ad aggiungere o togliere un numero di giorni, mesi o anni ad una data.
Sintassi:

Codice: Seleziona tutto

 DATEADD( <field>, <numeric value expr>, <datetime value expr> )

dove:

• <field> è una stringa che va posta fra apici semplici per indicare: 'dd' o 'day' (giorno), 'mm' o 'month' (mese), 'yy' o 'year' (anno)
• <numeric value expr> è il numero intero di giorni, mesi o anni da aggiungere o togliere (se negativo)
• <datetime value expr> è una data o il nome campo contenente una data

Esempi:

Codice: Seleziona tutto

DATEADD( 'dd', 5, "data1" )

aggiunge 5 giorni alla data contenuta nel campo data1

Codice: Seleziona tutto

DATEADD( 'month', -1, NOW() )

toglie 1 mese alla data odierna

[bydindi]

Tra le peculiarità di HSQLDB più interessanti c'è quella della stabilità rispetto al motore incorporato di Base;

Il funzionamento di Base con il motore HSQL incorporato è questo:
Ogni qualvolta apriamo un file con estensione .odb esso viene "scompattato" (infatti i file .odb sono file compressi) in questo modo abbiamo la possibilità di poterci lavorare creare tabelle, query, formulari ecc. e inserire i vari dati che andranno a popolare le varie tabelle.
Ogni qualvolta chiudiamo un file .odb esso viene nuovamente compresso e verrà nuovamente decompresso/scompattato al suo successivo riutilizzo.
Capita però talvolta che l' operazione di compressione non vada a buon fine oppure che si incontrino dei problemi durante l'utilizzo di Base (ad esempio un blocco del PC o peggio ancora un black out improvviso)
Nella peggiore delle ipotesi il file sul quale stavamo lavorando non si può più riaprire (anche se in molti casi i dati si possono comunque recuperare);
nella "migliore" delle ipotesi il file "corrotto" viene recuperato in automatico da openoffice stesso ma purtroppo le ultime modifiche apportate e gli inserimenti dei nuovi dati nelle tabelle sono irrimediabilmente persi.
Un esempio pratico che purtroppo capita (per fortuna non spesso) a me medesimo:
Apro il mio database inserisco un nuovo cliente e con quest'ultimo apro un nuovo contratto, dopo di che stampo il contratto lo faccio firmare
ecc. , a questo punto il PC si blocca (per cause non necessariamente imputabili a openoffice) e sono costretto a chiudere forzatamente il database.
Alla riapertura del file mi accorgo che il nuovo cliente e il contratto associato non sono più presenti nel database ( "volatilizzati"), allora sono costretto a prendere la copia cartacea del contratto e reinserire nuovamente i dati che sono andati persi (inserimento nuovo cliente, riapertura del contratto ecc.)
Immaginate se un blackout avviene subito dopo aver aperto una decina di contratti..... un macello!!!!!

Con il metodo suggerito da Charlie si utilizza HSQLDB 2.3.2 che è un motore estrno a Base, è più stabile e il file in pratica rimane sempre scompattato scongiurando così i problemi che sorgono con il motore incorporato (problemi che ho elencato sopra).
Ho provato personalmente ad aggiungere una decina di dati in una tabella, spegnere forzatamente il PC con il file aperto e al successivo riavvio aprire nuovamente il file
e trovare TUTTI i dati inseriti come se non fosse successo niente!!!
Purtroppo però anche questo metodo non è esente da "problemi", nel mio caso (utilizzo openoffice anche per la fatturazione) il calcolo delle approssimazioni
nei numeri decimali viene effettuato in maniera diversa dal HSQL e quindi le fatture (imponibile IVA e totale) in alcuni casi non vengono calcolati in maniera corretta
(a causa appunto delle approssimazioni) con HSQL mi trovo ad esempio un imponibile di 120,23 (è solo un esempio giusto per intenderci) mentre con HSQLDB lo stesso calcolo mi da un imponibile di 120,22

Per ora mi fermo quì (mi rendo conto di essere stato prolisso) ma mi interessa il parere di altre persone che hanno provato e/o utilizzano HSQLDB

p.s. un altro metodo (sempre proposto nel forum inglese) è quello di utilizzare HSQLDB su un file già esistente (il procedimento è un po' macchinoso ma in questo caso il calcolo di approssimazione è lo stesso di HSQL)

P.s. 2 tempo fà ci fu un interessamento di Vladko per la traduzione in italiano dei due procedimenti proposti nel forum inglese....

Paolo

[bydindi]

questo è il mio post nel forum inglese in "inglese maccheronico "

https://forum.openoffice.org/en/forum/v ... 73#p343173

[charlie]

Il tuo problema dello scorporo dell'IVA si può risolvere adottando più di due decimali nelle tabelle (come mi pare ti fosse stato suggerito nel forum inglese).

[bydindi]

Ciao charlie, grazie per la risposta

Il problema è proprio questo

se calcolo l'iva su un imponibile di 12,30 il risultato è 2,71 in quanto il prodotto del calcolo 12,30*0,22 mi dà 2,706 che arrotondato sarà 2,71

con il database incorporato se inserisco un importo iva inclusa di € 15,00 e con una query estrapolo l'imponibile (15/1,22) il risultato è 12,30 e fino a quì i calcoli sono simili (anche HSQLDB mi da come risultato 12,30)
ora che ho ricavato l'imponibile devo fare la fattura che sarà:
IMPONIBILE+(IMPONIBILE*0,22(cioè l'iva))= totale
è quì che i due database si comportano in maniera diversa

database incorporato: importo iva inclusa (lo inserisco manualmente) € 15,00 e con le query avrò: imponibile 12,30 iva 2,71 TOTALE 15,01 <------calcolo CORRETTO!
HSQLDB : importo iva inclusa (lo inserisco manualmente) € 15,00 imponibile 12,30 iva 2,70 TOTALE 15,00 <-------calcolo errato in quanto l'iva (2,70) è sbagliata!!!!
come se prendesse in considerazione il valore assoluto dell'imponibile senza arrotondamento (12,29508) e moltiplicandolo per 0,22 dà come risultato 2,70491 che arrotonda a 2,70

tutto ciò non accade se seguo la procedura per "splittare" un database già esistente (nel tuo suggerimento invece fai riferimento alla creazione di un database ex-novo)

Per intenderci posso riepilogare con un quesito:

Se ho un importo IVA inclusa di euro 15,00 quanto sarà l'imponibile? quanto sarà l'iva (al 22%)?

Paolo

[charlie]

Alcune precisazioni:

1. entrambe i motori sono HSQLDB, versione 1.8 quello incorporato in Base, 2.3.2 l'altro.
2. non mi pare tu mi abbia risposto: adottando 5 cifre decimali dopo la virgola, il problema dello scorporo dell'IVA si risolve, secondo le mie prove.
3. non ho ancora provato l'altro modo di split database, lo farò quanto prima.

[bydindi]

Ciao charlie

entrambe i motori sono HSQLDB, versione 1.8 quello incorporato in Base, 2.3.2 l'altro.

Mea culpa, aprendo il database con il motore interno leggo solo HSQL e non la versione quindi per mia (ripeto mia) errata convinzione ritenevo il motore interno
"HSQL" e il mootore esterno "HSQLDB"

non mi pare tu mi abbia risposto: adottando 5 cifre decimali dopo la virgola, il problema dello scorporo dell'IVA si risolve, secondo le mie prove.

ti ho risposto eccome!!! forse poco chiaramente ma ti ho risposto:

se calcolo l'iva su un imponibile di 12,30 il risultato è 2,71 in quanto il prodotto del calcolo 12,30*0,22 mi dà 2,706 che arrotondato sarà 2,71

ma tu nella tua immagine d'esempio mi indichi un calcolo sbagliato!!!
infatti partendo da un imponibile di 12,30 (quello che tu chiami iva) nel tuo esempio compare come importo "ivato" 15,00 che appunto è un errore!
se aggiungo l'iva ad un imponibile di 12,30 il totale deve essere 15,01 altrimenti stai "rubando" € 0,01 all'erario! perchè l'iva di 12,30 è 2,71!
infatti se imposti 5 decimali l'approssimazione non è corretta e il calcolo errato è presente anche nel motore incorporato (invece è corretto se imposto 2 cifre decimali)

facendo diverse prove (ma aimè non mi ritrovo più il file) ero riuscito comunque a fare l'approssimazione anche con HSQLDB 2.3.2.
(utilizzando nella query la funzione "round") purtroppo però era un'approssimazione errata, infatti impostando un imponibile di 12,30 mi dava come risultato un iva di 2,71
continuando le prove però mi sono accorto che la regola adottata per l'approssimazione era diversa da quella "richiesta" dall'agenzia delle entrate nell'ambito iva

infatti l' ADE richiede questo tipo di approssimazione:

Partendo dal presupposto che l'iva và rappresentata con un numero comprensivo di due cifre decimali

applicando l'aliquota IVA ad un determinato importo se il risultato dà un numero decimale di più di due cifre si procede in questo modo:
prendendo in considerazione la terza cifra decimale se questa è pari o inferiore a 4 ( e quindi vale per le cifre 0,1,2,3,4) la seconda cifra decimale rimane invariata
ad esempio un importo iva di 3,564 diventa 3,56 (approsimazione per difetto)

se la terza cifra decimale è una cifra superiore a 4 (e quindi le cifre 5,6,7,8,9) la seconda cifra decimale va approssimata alla cifra superiore
ad esempio un importo di 2,706 diventa 2,71(approssimazione per eccesso)

invece HSQLDB adotta come regola la seguente:
se la terza cifra è 0,1,2,3,4 e 5 si approssima per difetto e per le restanti cifre 6,7,8,9 si approssima per eccesso

infatti un importo di 2,3452 (che "sarebbe" l'iva di 10,66) viene arrotondato a 2,34 (e in ambito IVA non è corretto)

nell'esempio che allego se analizzi la query noterai che lo stesso calcolo viene eseguito sia su un numero decimale a due cifre sia su un numero a 5 decimali
e il risultato è diverso (è "buono" quello con il decimale a due cifre)

La stessa prova fatta su HSQLDB "splittato" da risultati differenti e non congrui per il calcolo di imponibile e iva partendo da un importo TOTALE (imponibile+iva)

con la versione "split" utilizzando un database già esistente, invece il calcolo effettuato dalle query e "corretto", il mio dubbio (il dubbio che ho esposto nel forum inglese)
sull'utilizzo del "database splittato già esistente" era solo se vi erano differenze tra le due versioni di HSQLDB (quella suggerita da te partendo da un database exnovo è (dovrebbe essere) più recente e magari con correzioni di bug presenti nella versione precedente )