leggere tabelle di DB SQLite3 con Zeos

[petrusic]

Ho bisogno di risalire all'ultimo numero progressivo di record di diverse tabelle di DB Sqlite3.
Da quando ho cominciato a muovermi in lazarus, affidandomi a Zeoslib, ho difficoltà ad eseguire una open della connessione al DB per eseguire successivamente le Query, Insert, Update, Delete che servono. Infine,  comandare una unica CommitUpdates o CancelUpdates alla fine di ciascun ramo logico di operazioni.
Zeoslib non permette di eseguire la Open della connessione al DB, ma alla singola Query. L'oggetto ZQuery è l'unico agganciato alla procedura Open.
Pertanto il codice che segue funziona solo per la prima tabella. dopo di che, il programma innesca una sorta di ciclo infinito.

Codice: [Seleziona]

 sql:= 'SELECT movimgg.IdMovvgg AS FROM movimgg ORDER BY IdMovvgg DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text:= sql;
  Form1.ZQuery1.Open;
  Form1.ZQuery1.First;
  movimggNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdMovvgg').AsString);

  sql:= 'SELECT IdPartGlob FROM partmovv ORDER BY IdPartGlob DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text:= sql;
  Form1.ZQuery1.ExecSQL;
  Form1.ZQuery1.First;
  partmovNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdPartGlob').AsString);

  sql := 'SELECT IdPrestMom FROM prestmom ORDER BY IdPrestMom DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text := sql;
  Form1.ZQuery1.ExecSQL;
  Form1.ZQuery1.First;
  prestmomNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdPrestMom').AsString);

  sql := 'SELECT IdResCasgg FROM restacassagg ORDER BY IdResCasgg DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text := sql;
  Form1.ZQuery1.ExecSQL;
  Form1.ZQuery1.First;
  restaCassaNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdResCasgg').AsString);      

Posso risolvere in qualche modo o devo creare tante query quanti sono gli accessi caldi al DB, prima di andare avanti

Penso infatti a come dovrei procedere quando dovrò inserire righe in tabelle diverse, per confermarle o annullarle alla fine di tutti gli inserimenti, pertinenti allo stesso insieme di dati.

[xinyiman]

Prova così

Codice: [Seleziona]

 sql:= 'SELECT movimgg.IdMovvgg AS FROM movimgg ORDER BY IdMovvgg DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text:= sql;
  Form1.ZQuery1.Open;
  Form1.ZQuery1.First;
  movimggNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdMovvgg').AsString);
  Form1.ZQuery1.Close;

  sql:= 'SELECT IdPartGlob FROM partmovv ORDER BY IdPartGlob DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text:= sql;
  Form1.ZQuery1.Open;
  Form1.ZQuery1.First;
  partmovNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdPartGlob').AsString);
  Form1.ZQuery1.Close;

  sql := 'SELECT IdPrestMom FROM prestmom ORDER BY IdPrestMom DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text := sql;
  Form1.ZQuery1.Open;
  Form1.ZQuery1.First;
  prestmomNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdPrestMom').AsString);
  Form1.ZQuery1.Close;

  sql := 'SELECT IdResCasgg FROM restacassagg ORDER BY IdResCasgg DESC LIMIT 1';
  Form1.ZQuery1.SQL.Text := sql;
  Form1.ZQuery1.Open;
  Form1.ZQuery1.First;
  restaCassaNumId:= StrToInt(Form1.ZQuery1.FieldByName('IdResCasgg').AsString);     
  Form1.ZQuery1.Close; 

Quando apri un recordset, per poterlo riutilizzare devi chiudere quello precedente.
Poi EXECSQL si usa per eseguire una sql che non ritorna valori, se devi recuperare valori devi usare la open (e quindi la close di conseguenza).

[DragoRosso]

In generale è buona cosa come ha detto @xinyiman:

1) Chiudere la query;
2) Impostare la sentenza SQL;
3) Aprire la query;

Per Aprire e Chiudere, oltre a Open e Close, si può usare la proprietà Active (True e False).
Giusto per la cronaca, ma sconsigliato, si può anche solo impostare la proprietà SQL e poi settare la proprità Active a True senza fare il Close o settare Active a False: ZEOS "chiude" la query automaticamente se si setta la proprietà SQL.

Invece è interessante la necessità riguardante la validazione di una serie di "commit" di un insieme di transazioni singole.
Varie scritture su varie tabelle sono molte volte necessarie per completare un sessione di aggiornamento.
Ma effettivamente c'è uno "strumento" che consente di effettuare un rollback di tutte le transazioni interessate nel caso qualcosa non vada a buon fine?

In tutti questi anni a me non è mai servito, o meglio non è mai successo alcunchè per cui fosse necessario effettuare un rollback, ma effettivamente se ci fosse lo implementerei sicuramente.

[petrusic]

Quando apri un recordset, per poterlo riutilizzare devi chiudere quello precedente.

Non lo sapevo di certo, ma l'avevo immaginato. Secondo me, Gambas lavora meglio coi DB.

Poi EXECSQL si usa per eseguire una sql che non ritorna valori, se devi recuperare valori devi usare la open (e quindi la close di conseguenza).

Questo non lo sapevo proprio. Grazie.

Tornando al mio problema, Si, come mi hai suggerito, funziona. l'ho già provato nel pomeriggio, prima che arrivasse la tua risposta. Perciò questa parte di programma posso anche lasciarla come l'ho già modificata, conformemente al tuo suggerimento.

Tuttavia, non risolverei del tutto. Infatti, mi trovo di fronte alla seguente necessità:
1) Devo Inserire righe nuove in una 1.^a  tabella (movimgg)
2) Devo Inserire righe nuove in una 2.^a  tabella (prestmom)
3) Devo Inserire righe nuove in una 3.^a  tabella (restacassagg)
4) Devo Inserire righe nuove in una 4.^a  tabella (riepmovg)
5) Devo anche aggiornare 2 campi di un'ulteriore 5.^a  tabella (piancont)

Ma, poichè tutti i dati da inserire hanno la stessa data di calendario, non posso eseguire tante Open  con altrettante Close distinte, perchè con la Close, da quanto ho capito, si scatena un Commit automatico. E se mi trovassi, per la manifestazione di un casuale errore, nella necessità di operare un rollback, non sarei più in grado di farlo.

Una realtà del genere significherebbe, per me, dover rinunziare a Zeoslib ed orientarmi su qualcos'altro. Al punto in cui sono arrivato, sarebbe un vero disastro in termini di tempo ed impegno.
Spero tanto che ci sia una via d'uscita pratica ed efficace.

[petrusic]

è interessante la necessità riguardante la validazione di una serie di "commit" di un insieme di transazioni singole.
Varie scritture su varie tabelle sono molte volte necessarie per completare un sessione di aggiornamento.
Ma effettivamente c'è uno "strumento" che consente di effettuare un rollback di tutte le transazioni interessate nel caso qualcosa non vada a buon fine?

Molto appetibile questa tua indicazione, ma dove potrei trovare la spiegazione sull'argomento?

In tutti questi anni a me non è mai servito, o meglio non è mai successo alcunchè per cui fosse necessario effettuare un rollback, ma effettivamente se ci fosse lo implementerei sicuramente.

Personalmente, non mi trovi d'accordo sull'aspettare che l'evento negativo si manifesti per gestirlo. Occorre, secondo me, prevederlo sin dalla progettazione ed inserirne il relativo codice, alfine di non doverci tornare sopra a distanza di tempo, dopo avere, magari, dimenticato la logica dei dettagli del codice scritto.

[DragoRosso]

Molto appetibile questa tua indicazione, ma dove potrei trovare la spiegazione sull'argomento?

Non lo sò, era la mia appunto una domanda rivolta alla community.

Personalmente, non mi trovi d'accordo sull'aspettare che l'evento negativo si manifesti per gestirlo. Occorre, secondo me, prevederlo sin dalla progettazione ed inserirne il relativo codice, alfine di non doverci tornare sopra a distanza di tempo, dopo avere, magari, dimenticato la logica dei dettagli del codice scritto.

Assolutamente d'accordo con te. Per ovviare a ciò, in tutte gli eventi di scrittura (tipo beforepost), ho sempre "super controllato" tutti i dati. E in tutti questi anni non è mai successo niente sui database dei miei clienti. Certo l'interruzione di corrente è sempre in agguato, lo spegnimento inopportuno del PC (foss'anche un server) anche, come pure un blocco anomalo.

Sino ad ora non avevo trovato nessuna funzione che mi consentisse di gestire queste eventuali situazioni (e non penso ce ne siano a meno di andare con sistemi a pagamento professionali). Però almeno se ci fosse qualche funzionalità che protegga in maniera normale, come una "sessione" ad esempio, la userei.

Non sono un superesperto di database, ho usato ISAM (anni 80), poi DBASE, Paradox, MSDE, MS SQL Express ed infine SQLite. Li uso per scopi industriali (compreso qualche anagrafica), ma non certo a livello gestionale come in un sistema contabile.

Vediamo se qualcuno con più esperienza sui database ci può illuminare.

Saluti

[Stilgar]

Ciao.
Vedendo i frammenti di codice, mi verrebbe da suggerirti http://www.lazaruspascal.it/index.php?page=111.
Se utilizzi il codice per manipolare il codice e non ti piace lavorare con l'open/close e altre cose ereditate da Delphi, utilizzando le interfacce puoi addirittura non distruggere le istanze degli oggetti (uscendo dallo scope di esecuzione, se possibile, vengono distrutti in automatico).
Tramite le interfacce puoi eseguire le begin transaction e commit/rollback a seconda delle esigenze.

Codice: [Seleziona]

     
Type 
IZConnection = interface  [....]  procedure Commit;      procedure Rollback;    procedure PrepareTransaction(const transactionid: string);       
  procedure CommitPrepared(const transactionid: string);       
  procedure RollbackPrepared(const transactionid: string); procedure Commit;  
  [....]

Caso tipico, inizi la transazione, tra il try ed exception metti le tue operazioni a db, poi se tutto va bene chiami la commit o se ci sono eccezioni la rollback.
Vedendo le istruzioni di sqlite, potresti fare delle chimate dirette al motore con

Codice: [Seleziona]

 
function Execute(const SQL: ZAnsiString): Boolean; overload;

per gestire a tuo piacimento le transazioni.
https://sqlite.org/lang_transaction.html

Dal componente della connessione visuale puoi ottenere l'interfaccia alla connessione.
Poi puoi fare quel che vuoi.
https://github.com/delphipascal/zeoslib/blob/master/zeos-7.0.4/src/dbc/ZDbcIntfs.pas

Se vuoi utilizzare solo componenti visuali, dovresti (stando alla filosofia dei componenti) definirti un'oggetto query per ogni query che pensi dover lanciare.
Personalmente, visto che scrivi le query nel codice, ti suggerisco la strada a "basso" livello con Zeos.

[DragoRosso]

@Stilgar

Quindi, per farla semplice in modo quasi universale, uno potrebbe fare prima della "prima" scrittura un SAVEPOINT nominato, poi fare le scritture successive e se qualcosa và male fa un ROLLBACK TO ... e non prosegue, se invece alla fine è andato tutto OK fà un RELEASE.

Interessante, non avevo mai approfondito l'argomento.

Provo subito con alcuni progetti.

Grazie mille

[petrusic]

@ Stilgar
Si, hai capito perfettamente. Non sono abituato a lavorare sui DB tramite open/close. Mi piace prepararmi la mia brava riga col comando SQLite e mandarla in esecuzione, praticamente, in via transazionale.
Ho riletto l'argomento che mi hai suggerito:

Vedendo i frammenti di codice, mi verrebbe da suggerirti http://www.lazaruspascal.it/index.php?page=111.

Devo dire che non mi trovo con la terminologia ivi contenuta, perchè non vi sono abituato, Non capisco infatti quando dici:

Per "accendere" il motore di ZEOS Low Level, basta una semplice chiamata:
var Connection : IZConnection;
..
  Connection := DriverManager.GetConnection(connectionURL);

La riga "var Connection:  IZConnection;" dovrebbe corrispondere alla " ZConnection1: TZConnection;" contenuta  nella sezione Interface del mio programma:

Codice: [Seleziona]

interface

uses
  Classes, SysUtils, DB, Forms, Controls, Graphics, Dialogs, StdCtrls, ComCtrls,
  ExtCtrls, fpspreadsheet, laz_fpspreadsheet, Process, ZConnection, ZDataset, utilmie,
  fpstypes; // , flcDynArrays; dovrebbe permettere di riordinare la seuenza degli elementi di un vettore

type

  { TForm1 }
  TForm1 = class(TForm)

   DataSource1: TDataSource;
    . . . 
    ZConnection1: TZConnection;
    ZQuery1: TZQuery;
    . . . 

La riga " Connection := DriverManager.GetConnection(connectionURL);" non la capisco, perchè non capisco Cosa chiami con "DriverManager".
 "DriverManager"  è forse il "DataSource1" che ho dichiarato sempre nella sezione Interface (cioè, uno degli oggetti di Zeos?)?
Prima di proseguire, ho bisogno di capire bene i riferimenti principali che permettono al programma utente di agganciarsi alle funzioni ZEOS.

[Stilgar]

Ciao.

Zeos è costruito a strati.

Quello che hai visto fino ad adesso è quello più esterno.

Il DriverManager è proprio una classe per i fatti suoi.

Nel tuo codice devi "adattare" il codice utilizzando:

Codice: [Seleziona]

var Connection:  IZConnection;
....
  Connection :=  ZConnection1.DbcConnection;
...

Quando indico "accendere" il motore, intendo dire attivare la connessione al database con tutto quello che ne consegue. (Caricamento della dll del driver vendor per l'accesso e altre cosine che fa internamente per garantirti l'accesso al database)

Ho cercato di non essere pesante ed entrare troppo nei dettagli ma dare un taglio più informare giusto per arrivare a come utilizzare le cose. Gli sviluppatori Java non hanno problemi di sorta con quelle interfacce, essendo simili a quelle di JDBC.

Stilgar

[petrusic]

Quando indico "accendere" il motore, intendo dire attivare la connessione al database con tutto quello che ne consegue. (Caricamento della dll del driver vendor per l'accesso e altre cosine che fa internamente per garantirti l'accesso al database)

Ho cercato di non essere pesante ed entrare troppo nei dettagli ma dare un taglio più informare giusto per arrivare a come utilizzare le cose. Gli sviluppatori Java non hanno problemi di sorta con quelle interfacce, essendo simili a quelle di JDBC.

Mi dispiace deluderti, ma non ho la preparazione che forse immagini.
Purtroppo, per capire, a causa della scarnissima documentazione trovata, navigando, posso solo  chiedere, e poi chiedere, e poi  . . .  ancora chiedere

Zeos è costruito a strati.
Quello che hai visto fino ad adesso è quello più esterno.

Il DriverManager è proprio una classe per i fatti suoi.
Nel tuo codice devi "adattare" il codice utilizzando:
[/size]

Codice: [Seleziona]

var Connection:  IZConnection;
....
  Connection :=  ZConnection1.DbcConnection;
...

A me non funziona:
Ho modificato la parte implementation del programma inserendovi la var Connection:

Codice: [Seleziona]

unit frmmain;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, DB, Forms, Controls, Graphics, Dialogs, StdCtrls, ComCtrls,
  ExtCtrls, fpspreadsheet, laz_fpspreadsheet, Process, ZConnection, ZDataset, utilmie,
  fpstypes; // , flcDynArrays; dovrebbe permettere di riordinare la seuenza degli elementi di un vettore

type

  { TForm1 }
{
--- bla --- bla ---
  TForm1 = class(TForm)

    DataSource1: TDataSource;
    leInfoMov: TLabeledEdit;
    PulsFine: TButton;
    PulsAvvia: TButton;
    Label1: TLabel;
    lsDir: TListBox;
    ZConnection1: TZConnection;
    ZQuery1: TZQuery;
    procedure PulsFineClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure PulsAvviaClick(Sender: TObject);
  end;

var
  Form1: TForm1;
implementation

{$R *.lfm}
uses
  frm2;

type
   TsSpreadsheetFormat = (sfExcel2, sfExcel5, sfExcel8, sfExcelXML, sfOOXML,
    sfOpenDocument, sfCSV, sfHTML, sfWikiTable_Pipes, sfWikiTable_WikiMedia, sfUser);   // sfOpenDocument è il tipo di formato valido per OpenOffice/LibreOffice.ods

const
    dirFogli: string = '/media/dirdati/dativari/ContDom/';

var

  Connection: IZConnection;
{ TForm1 }                                
--- bla --- bla ---

Il compilatore accende il seguente messaggio d'Errore:

frmmain.pas(75,15) Error: Identifier not found "IZConnection"
frmmain.pas(75,27) Error: Error in type definition

[DragoRosso]

La "IZConnection" è definita nell'unità "ZDbcIntfs" che devi inserire nelle Uses nella sezione Interface.

[DragoRosso]

@petrusic
Il discorso fatto @Stilgar, è per facilitare il controllo delle funzionalità per la gestione del database.
Usando le "interfacce" dirette, puoi accedere alle proprietà mascherate ed effettuare tutta una serie di operazioni che altrimenti sarebbe un pò più laboraioso fare.

Che differenza c'è tra l'uso di "componenti" e "interfacce"? Andando al sodo terra terra, diciamo che i componenti sono degli oggetti con funzionalità base (o meglio con le funzionalità che chi li ha creati pensa siano sufficienti) per svolgere nella maniera più semplice il proprio compito.

In genere i componenti hanno una controparte di "design" che consente di essere configurati a designtime ed evitando tutte quelle operazioni che si dovrebbero invece effettuare a codice. I componenti possono anche essere dichiarati e costruiti a codice (a runtime quindi), normalmente bisogna però porre attenzione a settare le proprietà nella giusta sequenza.
I componenti hanno dei limiti, che sono essenzialmente quelli legati alla facilità d'uso. E alcune volte anche dei limiti nell'uso in applicazioni multithread.

Usando invece le interfacce, si ha accesso quasi completo alla funzionalità, migliorando l'efficienza. Come controaltare ho che le "interfacce" possono essere usate solo a codice (quindi "costruite" a runtime). Inoltre è necessario settare ogni singola proprietà conformemente all'uso, là dove il componente invece già svolgeva tale compito in modo mascherato.

Per chi non ha molta esperienza, e per chi non ha la possibilità di approfondire l'argomento, è consigliato l'uso dei componenti, magari piano piano costruiti a runtime invece che a designtime.

Saluti

[petrusic]

La "IZConnection" è definita nell'unità "ZDbcIntfs" che devi inserire nelle Uses nella sezione Interface.

Hai ragione, era scritto nella guida che mi ha suggerito di leggere Stilgar. Ora il compilatore l'ha riconosciuto.

In genere i componenti hanno una controparte di "design" che consente di essere configurati a designtime ed evitando tutte quelle operazioni che si dovrebbero invece effettuare a codice.
. . .

Ti ringrazio per la tua riflessione. In realtà non ho esperienza di interfacce grafiche per la gestione di DB e l'unico tipo di DB che conosco è SQLite, anche se professionalmente, tanti anni fa, ormai, ho conosciuto il CICS IBM ed ho imparato a costruire Database relazionali.
Con Gambas ho sempre gestito gli accessi a DB tramite codice, mai con strumenti da interfacciamento grafico.

Tornando alla tua riflessione devo dire che mi aspettavo di leggere che, utilizzando i componenti, non fosse necessario ricorrere al loro design.
 
Invece, per quanto capisco, non posso fare a meno di mettere in campo quel minimo sindacale, costituito da  TDataSource, TZquery e TZConnection.

[DragoRosso]

@petrusic
Mio consiglio personale è di usare i componenti per quanto possibile, a meno che non ci siano necessità particolari, come prestazioni, multithreading spinto, limite all'uso delle risorse, etc ...

Principalmente sono due i motivi:

1) Compatibilità con il passato, presente e futuro: i componenti fatti bene funzioneranno ieri come domani, perchè chi li programma ha normalmente in mente il target a cui il componente deve arrivare. Inoltre innovare un componente mantenendolo perfettamente compatibile con il passato è relativamente semplice.

2) In genere i componenti sono pensati per evitare tutte le problematiche che potrebbero accadere: esempio è il settaggio di una proprietà che và a modificarne altre due.

Non è detto che le interfacce non abbiano lo stesso tali caratteristiche, ma esponendo il cuore del funzionamento è più probabile che siano meno retro comaptibili.

Io uso ormai da diversi anni SQLite, sicuramente non al 100% delle sue possibilità (vedi post arretrati). E quando connetto un database con un componente come TZConnection, poi uso tante query, table, dataset ....

In genere uno per ogni esigenza. Se ho quattro tabelle in uso, io creo 4 componenti query che operano in maniera autonoma (ma comunque sincronizzata in scrittura, perchè bisogna ricordarsi che SQLite è "monoscrittura").

Perchè devo aprire e chiudere continuamente le query se opero con diverse tabelle ? Genero una query e quella rimane attiva finchè lo decido io, perche su un'altra tabella userò un altro componente query.

Non c'è però da preoccuparsi, la tecnica arriva con l'esperienza e i progetti (almeno, questa è la mia storia) vivono di vita propria, evolvono con l'esperienza di chi li ha creati e li mantiene.

Saluti