RISOLTO Java e DataBase

[petrusic]

...
il programma funziona, ma ho dovuto commentare il blocco finally in letDb perché se chiudi il resultset non puoi visitarlo per leggerne i dati, quindi la chiusura va fatta dopo.

Seguendo il tuo esempio, ho commentato anch'io il blocco finally in letDB ed ho mandato in esecuzione il programma connettendo, però, sempre il mio ContabFamdb.
Purtroppo non riesco ad andare avanti. L'errore alla connessione si manifesta sempre.

Quindi, posto che sia stato correttamente linkato il jar del driver jdbc di SQLite al build path del progetto Eclipse,
forse c'è un problema nel percorso del db.

Scusami Fabio, ma non capisco quello che vuoi dire.
Ti riferisci alla posizione del file .jar a cui si dovrebbe appoggiare eclipse per la ricerca del driver JDBC di SQLite?
Oppure tiriferisci al contenuto della String dbPath (String dbPath = "jdbc:sqlite:/media/dirdati/dativari/contabfam/ContabFamdb";) di riga 43 del programma?

Io posso dirti:
- Il sorgente si trova in: /media/dirdati/dativari/java_vari/eclipse-workspace/ContFamCancResta/src/ContFamCancResta.java
- il DB si trova in: /media/dirdati/dativari/contabfam/ContabFamdb
- i file .jar si trovano in /usr/share/java
- i file eclipse si trovano in /home/petrus/eclipse-2018-12:
artifacts.xml dropins eclipse.ini icon.xpm plugins
configuration eclipse features p2 readme
(non c'è il file workspace perchè l'ho spostato per omogeneità archivio sorgenti miei)

 

[fabio93]

Hai aggiunto il file .jar del driver jdbc al build path del progetto? Ripeto i passi da fare:
fai clic col tasto destro sulla cartella del progetto e seleziona Build Path -> Configure Build Path. Poi, dalla scheda Libraries, fai clic su Add External JARs e seleziona il file .jar del driver jdbc (sqlite-jdbc-3.28.0.jar). Clicca su Apply and Close per confermare.
Se hai seguito questa procedura e l'errore si verifica comunque, potrebbe esserci un problema relativo al percorso del db indicato nella stringa dbPath. Perciò per escludere questa eventualità potresti provare a fare una query sul db di esempio di SQLite ("jdbc:sqlite:sample.db") come ho fatto io. Come query puoi usare "select * from person", e recuperare i risultati dal resultset con:

while(rs.next()) {
    // read the result set
    System.out.println("name = " + rs.getString("name"));
    System.out.println("id = " + rs.getInt("id"));
}

Aggiungo, per chiarezza, che il db di esempio dev'essere stato prima creato eseguendo la classe Sample presente nel repository GitHub di SQLite, altrimenti ovviamente le query non funzioneranno.

 

[petrusic]

Hai aggiunto il file .jar del driver jdbc al build path del progetto? :

No! Non avevo capito che bisognava farlo per ciascun nuovo progetto. Pensavo che, una volta fatto per il primo progetto, e l'avevo fatto per un ulteriore programma, momentaneamente accantonato, fosse stato disponibile ed usabile anche per altri progetti successivi.
:muro:

Risolvendo l'anomalia relativa alle librerie sqlite-jdbc.jar, ho ritrovato il mio DB ed ho potuto eseguire intanto la mia 1.a query.

Questo è stato veramente un grosso passo avanti.
Gra-zi-e !!!

 

[fabio93]

Di nulla! :ok:

 

[petrusic]

Bene. Oggi ho finito il 1° programmino che aggiorna una tabella di DB. L'ho provato e riprovato e ... funziooooonaa.
:brindiamo:

Ora dovrei svolgere i seguenti passi:
- ricavare un file eseguibile del programma, direttamewnte da linea di comando, senza dovere scomodare ogni volta Eclipse;
- trasferire la "Class GestDB" in un pacchetto esterno (Es. UtilMie) per poterla richiamare all'occorrenza attraverso un'istruzione Import.
- infine, credo che sia finalmente arrivato il momento di imparare ad usare l'interfaccia grafica, mio :zzz: ab-origine delle mie conoscenza con Java.

La strada da percorrere è ancora lunga come lungo e pesante è l'impegno che ancora mi aspetta, ma, penso, che ormai non posso più cambiare linguaggio. Il virus Javaiolo è dentro di me :hihi:


Ho incontrato, durante questo piccolo percorso di crescita difficoltà nell'eseguire la seguente istruzione SQL:

---
GestDB conn = new GestDB(dbPath);
...
sql = "SELECT COUNT(*) as Conta FROM restacassagg  WHERE DtResCasgg = " + dt2;
nuRec = conn.toRecDB(sql);
...
class GestDB {
...
public int toRecDB(String sql) {           
            ResultSet rs = null;
            try {
                Statement stmt = conn.createStatement();
                int cont = stmt.?...?;       // con cui avrei dovuto prendere il caruico il contenuto di Conta (vedi Select sopra)
                return cont;

Quindi, avrei dovuto eseguire la lettura dell'alias Conta indicato nel comando SQL precedente, ma non ho capito come fare.

Ho risolto, eseguendo la scansione di tutto il ResultSet e totalizzando il numero dei record in esso contenuti, quando potevo farne a meno. Ora non credo che non ci sia una libreria con cui java sfrutti la suddetta caratteristica di SQLite. Ho anche cercato sul web un esempio simile fra le casistiche disponibili, ma non ho trovato niente.

 

[fabio93]

- ricavare un file eseguibile del programma, direttamente da linea di comando, senza dovere scomodare ogni volta Eclipse;

Per ricavare un eseguibile (in formato .jar) da Eclipse fa' clic destro sul progetto (o clic sinistro sul menu File) e seleziona Export, poi sotto Java seleziona Runnable JAR file, clicca su Next, seleziona la classe contenente il metodo main in Launch configuration e scrivi il percorso (a piacere) e il nome dell'eseguibile da generare in Export destination. Clicca su Finish per generare l'eseguibile.
Lo puoi eseguire da terminale con il comando java -jar nomeFile.jar

trasferire la "Class GestDB" in un pacchetto esterno (Es. UtilMie) per poterla richiamare all'occorrenza attraverso un'istruzione Import.

Per creare un package, fa' clic destro sul progetto e seleziona New->Package. Da' un nome al package (per convenzione in minuscolo, ma non è obbligatorio). Dopodiché, all'interno del nuovo package, crea una classe GestDB e trasferisci il codice della classe con taglia e incolla, ad esempio. Affinché la classe sia visibile all'esterno del package (e quindi utilizzabile da ContFamCancResta), dovrà avere visibilità public (quindi public class GestDB {...}), e ovviamente per utilizzarla in ContFamCancResta dovrai importarla con una import. A questo proposito, se posizioni il mouse sulla dichiarazione dell'oggetto GestDB alla linea 73 di ContFamCancResta, dove comparirà un segno di errore dopo aver spostato la classe GestDB, Eclipse mostrerà un riquadro con l'opzione per aggiungere l'import, senza doverla scrivere manualmente.
Questo genere di aiuti Eclipse li da anche per aggiungere i try/catch quando viene invocato un metodo che potrebbe sollevare un'eccezione, ad esempio.

Quindi, avrei dovuto eseguire la lettura dell'alias Conta indicato nel comando SQL precedente, ma non ho capito come fare.

La lettura dell'alias va fatta sempre tramite il resultset (qui sotto rs), per esempio con:
System.out.println("num. record = " + rs.getString("Conta"));

infine, credo che sia finalmente arrivato il momento di imparare ad usare l'interfaccia grafica, mio :zzz: ab-origine delle mie conoscenza con Java.

Per quanto riguarda la grafica, potresti usare Swing o JavaFX. Sono le due librerie grafiche di Java. Tuttavia JavaFX non è incluso nelle JDK per Linux e, dalla versione 11, nemmeno in quelle per Windows, per consentirne uno sviluppo svincolato dalle release di Java. Quindi dovresti scaricarlo a parte. Swing è invece incluso e funziona sempre, tuttavia è un po' farraginoso da usare, soprattutto per la gestione dei layout.
Ci sarebbe anche SWT che è la libreria con cui è fatto Eclipse, ma non so niente a riguardo.

 

[petrusic]

Per ricavare un eseguibile (in formato .jar) da Eclipse ...

:shock:
Quanta nuova carne sul fuoco!

Un vecchio detto IBM invita ad affrontare le difficoltà una alla volta. Solo così diventano semplici e facilmente superabili.

Perciò, prendo nota di tutte le tue indicazioni, ma, sicuramente non le affronterò tutte domani.
Ti terrò informato.

 

[petrusic]

Per creare un package, fa' clic destro sul progetto e seleziona New->Package. Da' un nome al package (per convenzione in minuscolo, ma non è obbligatorio). Dopodiché, all'interno del nuovo package, crea una classe GestDB e trasferisci il codice della classe con taglia e incolla, ad esempio. Affinché la classe sia visibile all'esterno del package (e quindi utilizzabile da ContFamCancResta), dovrà avere visibilità public (quindi public class GestDB {...}), e ovviamente per utilizzarla in ContFamCancResta dovrai importarla con una import. A questo proposito, se posizioni il mouse sulla dichiarazione dell'oggetto GestDB alla linea 73 di ContFamCancResta, dove comparirà un segno di errore dopo aver spostato la classe GestDB, Eclipse mostrerà un riquadro con l'opzione per aggiungere l'import, senza doverla scrivere manualmente.
Questo genere di aiuti Eclipse li da anche per aggiungere i try/catch quando viene invocato un metodo che potrebbe sollevare un'eccezione, ad esempio.

Ho cominciato a lavorare sulla creazione del nuovo pacchetto che dovrà ospitare GestDb e seguendo le tue indicazioni:

Click destro sul progetto (ContFamCancResta della finestra Esplora Progetti di Eclipse);
--> click su Nuovo --> click su Pacchetto

si apre la finestra Nuovo pacchetto Java contenente la dicitura:
crea cartelle corrispondenti ai pacchetti,
seguita da due caselle di digitazione.
1.a Cartella di origine: "ContFamCancResta/src" preimpostato
2.a Nome: (vuoto), pronta a ricevere il nome del pacchetto in creazione
(poi sotto c'è ancora un casellina da attivare un create package-info.java).
Ma, in questo modo mi sembra che il nuovo pacchetto non sia indipendente, ma sia figlio del progetto ContFamCancResta.
Quindi, se chiamo il nuovo pacchetto UtilMie, per richiamare GestDb, l'import deve citare sempre ContFamCancResta.UtilMie.GestDB
???

 

[fabio93]

No, è normale che sia così perché i package sono cartelle.

 

[petrusic]

No, è normale che sia così perché i package sono cartelle.

Ho guardato questa guida con video dimostrativo che crea due package distinti.
Entrambi i package sono definiti dentro la cartella src di un progetto principale. É però vero che l'istruzione import indica solamente il nome del package, trascurando il nome del progetto entro il quale il package è stato generato.
Ciò mi porta a pensare di creare un progetto "PacchettiMiei", dentro il quale generare poi il pacchetto "Utillità". Ciò allo scopo di dare vita ad un ambiente di pacchettizzazione personale distinto dai progetti applicativi dentro cui potere scrivere gli import opportuni ai futuri pacchetti personali.
Così posso dare già un'impostazione costruttiva al mio ambiente complessivo destinato a java, secondo il mio ordine mentale.

 

[fabio93]

Si può fare. Una volta completate, potresti creare un libreria in formato .jar che racchiuda tutte le classi di utilità.
Comunque per dire ad Eclipse di usare sorgenti da un altro progetto, devi cliccare col tasto destro sul progetto, scegliere Build Path->Configure Build Path e, dalla scheda Projects, cliccare su Add e indicare il progetto da cui attingere le classi.

 

[petrusic]

Si può fare. Una volta completate, potresti creare un libreria in formato .jar che racchiuda tutte le classi di utilità.
Comunque per dire ad Eclipse di usare sorgenti da un altro progetto, devi cliccare col tasto destro sul progetto, scegliere Build Path->Configure Build Path e, dalla scheda Projects, cliccare su Add e indicare il progetto da cui attingere le classi.

Allora, se non ho capito male, posso usare il comando import solo relativamente a pacchetti creati all'interno dello stesso progetto, o presenti nel progetto utilità.
Perciò, se voglio richiamare una o più classi con import, devo:
a) replicare il pacchetto utilità in ciascun nuovo progetto.
b) creare un progetto utilità dove caricare tutti i pacchetti di utilità di cui avessi bisogno e ogni volta che volessi richiamare almeno una classe contenuta in quest'ultimo progetto, dovrei scegliere Build Path->Configure Build Path e, dalla scheda Projects, cliccare su Add e indicare il progetto da cui attingere le classi. Solo dopo tale tipo di procedimento, potrei utilizzare import utilità.nomeClasse.
Utilità diverrebbe pertanto il nome con cui creare il progetto ed il pacchetto con tutte le relative classi.

 

[fabio93]

a) replicare il pacchetto utilità in ciascun nuovo progetto.
b) creare un progetto utilità dove caricare tutti i pacchetti di utilità di cui avessi bisogno e ogni volta che volessi richiamare almeno una classe

La a) e la b) sono alternative ovviamente.

Utilità diverrebe pertanto il nome con cui creare il progetto ed il pacchetto con tutte le relative classi .

Non è detto che progetto e suoi package abbiano lo stesso nome

 

[petrusic]

La a) e la b) sono alternative ovviamente.

Non è detto che progetto e suoi package abbiano lo stesso nome

Bene. Proverò a questo punto a seguire il criterio b). :ok:

 

[petrusic]

Oggi posso dire di avere raggiunto finalmente un buon risultato.
Infatti sono riuscito col mio programmino a generare un nuovo database SQLite ed a creare le tabelle che dovrà contenere.
Non mi piacciono due aspetti che non sono riuscito a condurre a modo mio:
1) verificare l'esistenza del DB prima di generarlo, però ho letto che la procedura di connessione attraverso il JDBC genera automaticamente il database, qualora non dovesse esistere. --> e tale comportamento mi sta bene
2) per creare la tabella ho seguito un esempio contenente nell'istruzione sql di creazione tabella uno statement come il seguente

CREATE TABLE IF NOT EXISTS schede

dove "schede" è il nome della tabella. --> Su tale modello di istruzione sono rimasto a lungo perplesso, temendo la possibilità di perdere i dati già presenti nella tabella, perchè, avrei preferito la produzione di un eccezione , in caso di tabella esistente, da gestire a programma e non come una sorta di bypass dell'ostacolo.

Ho comunque rifatto la prova di creazione tabelle dopo averle già create e dopo avere inserito un record a manina in una delle tabelle del DB. Il risultato è che la tabella già valorizzata, è rimasta inalterata.