DBGrid, selezionare tutti i record visibili

[giacomarko]

purtroppo non è così, ma sicuramente non mi sono spiegato bene io,
intendevo dire che al componente standard TSQLQuery,  si possono assegnare contemporaneamente 4 diversi script SQL, come dicevo Select, Update, Insert e Delete che si eseguono in modo automatico semplicemente chiamando i metodi

Edit;
Post;
e hai aggiornato il record corrente

Insert;
Post;
e lo hai creato

questo diversamente dal componente TZQuery che ha solo una proprietà SQL, che può contenere un solo script SQL alla volta

poi tutto si può aggiustare e adattare.

Resto però perplesso sul perché, esclusivamente sul loop di selezione dei record della DBGrid, ci voglia tutto questo tempo

vorrei capire se effettivamente non c'è via di uscita

[DragoRosso]

purtroppo non è così, ma sicuramente non mi sono spiegato bene io,
intendevo dire che al componente standard TSQLQuery,  si possono assegnare contemporaneamente 4 diversi script SQL, come dicevo Select, Update, Insert e Delete che si eseguono in modo automatico semplicemente chiamando i metodi
Edit;
Post;
e hai aggiornato il record corrente
Insert;
Post;
e lo hai creato
questo diversamente dal componente TZQuery che ha solo una proprietà SQL, che può contenere un solo script SQL alla volta
poi tutto si può aggiustare e adattare.

Non sò se usi quei componenti a Designtime oppure li istanzi a Runtime. Se ti accontenti del runtime (io la stragrande maggioranza dei componenti li istanzio a runtime), li istanzi a runtime, puoi derivare la classe TZQuery e aggiungere tutti i metodi e le proprietà che vuoi.

Però, diciamo che sostituire quelle quattro funzioni non dovrebbe essere un grosso problema, anzi.

Resto però perplesso sul perché, esclusivamente sul loop di selezione dei record della DBGrid, ci voglia tutto questo tempo
vorrei capire se effettivamente non c'è via di uscita

Forse non è "esclusivamente" nel loop di selezione. Tieni presente che una singola operazione veniva effettuata in circa 40 ms., tempo visto singolarmente impercettibile.

Prova a fare 5000 inserimenti, 5000 update e 5000 select, sia con i componenti standard che con ZEOS e misura i tempi, magari scopri che in realtà è il sistema in generale che non è performante non solo la "selezione" (che comunque è composta da più fasi).

Pensa anche ad una sostituzione di Access, l'ultima versione (Access 2021) verrà mantenuta sino al 13/10/2026. Le future versioni saranno supportate solo a pagamento (subscription) tramite un piano 365.
Tutte le versioni precedenti di Access sono andate  in "fine vita" (eccetto 2106 e 2019 per i piani a pagamento (extended) che scadranno ad Ottobre 2025).

Se fai le prove di timing facci sapere i risultati.

Ciao

[giacomarko]

Ecco la descrizione dei test:

1. per calcolare i tempi ho utilizzato la tua unit "Diagnostics" (OTTIMA !) così da poter uniformare i dati e il metodo.
2. creato una piccola applicazione, un form con 2 DBGrid la prima (A) collegata via ODBC e la seconda (B) via ZConnector
3. sempre lo stesso DB MSAccess e la stessa tabella 3350 rec da 52 campi.

I° test con un un loop da inizio a fine senza fare nulla
Result:
A = 330 millisec 
B =   63 millisec

II° test con un un loop da inizio a fine dove leggo un campo stringa e lo assegno ad una var locale
Result:
A = 319 millisec 
B =   57 millisec

III° test con un un loop da inizio a fine dove "marco" ogni record per poter successivamente usare il Bookmark
Result:
A = 160.869 millisec
B = 104 millisec

Visti i risultati, da profano farei questa considerazione;

- Sicuramente il componente ZEOS è più performante di quello nativo ODBC di Lazarus, almeno 5 o 6 volte più veloce
- Pur considerando la differenza di prestazioni tra i due, la funzione di "marcatura" del componente ODBC ha un grosso problema, questo, a meno di non scoprire che esiste un qualche setting da attivare o disattivare.

Tornando a noi,

sì i componeneti li istanzio a runtime, e la tua idea non è male (vedrò più avanti come implementarla), ma ora per poter pensare ad un passaggio a ZEOS, visto che con il componente ZEOS non ho la possibilità di usarlo contemporaneamente per tutte le operazione CRUD, credo che l'unica via (o meglio forse la più spiccia) sia quella di istanziare una seconda ZQuery e assegnargli lo script SQL che di volta in volta serve,

cosa ne pensi... vedi altre soluzioni ?

La sostituzione di Access non è un problema, la ditta che utilizzerà l'applicazione ha già da ora attivo 365 per tutti, e se dovesse essere comunque necessario cambiare in futuro, mi diranno lo cosa usare, anche perchè il porting dei dati lo chiederanno a me.

[DragoRosso]

Generalmente funziona come hai detto tu: o si sostituisce la "stringa" di query oppure si usano più ZQuery, diciamo specializzate, per fare diverse operazioni.

Non cambia molto dal fatto che ci possa essere un componente che può essere "preimpostato" per eseguire le quattro funzioni basilari.

Io normalmente uso una o due ZQuery e cambio la stringa. Molte volte, ma dipende ovviamente da come gestisci il tuo DB, lavoro direttamente con le ZTable e imposto il modo corrispondente (EDIT, INSERT, DELETE).

Occhio alle transaction e ai commit. ZEOS, se non sbaglio supporta una sola transaction per connessione.

Anche qui molto spesso io uso la transaction e il commit manuali, così che ho un controllo un pò più "fine" su ciò che accade.

Quello che ho detto si basa sulla poca esperienza su Zeos e Lazarus, in quanto in produzione uso normalmente Delphi e FireDac (che però hanno funzionalità molto simili).

Ciao

[DragoRosso]

Se vuoi informazioni basilari su Commit e Transaction in ZEOS, puoi leggere questo topic (o fare una ricerca): https://www.lazaruspascal.it/index.php?topic=2672.0

[giacomarko]

Io normalmente uso una o due ZQuery e cambio la stringa. Molte volte, ma dipende ovviamente da come gestisci il tuo DB, lavoro direttamente con le ZTable e imposto il modo corrispondente (EDIT, INSERT, DELETE).

in passato facevo così, poi smisi giusto per la possibilità offerta dal componente standard, ma non è un problema

Occhio alle transaction e ai commit. ZEOS, se non sbaglio supporta una sola transaction per connessione.

Anche ODBCConnection amette una sola Transaction per connessione

Anche qui molto spesso io uso la transaction e il commit manuali, così che ho un controllo un pò più "fine" su ciò che accade.

io lo stesso ;-)

grazie per l'esempio su ZEOS e l'aiuto

buona giornata

Marco

[giacomarko]

Chiudo con un commento e una precisazione, magari può essere di aiuto per altri.

Alla fine ho deciso di seguire il suggerimento di Bonmario e sostituire TODBCConnection con TZConnection, e ho toccato con mano cosa significa una modifica del genere anche se in un programma relativamente piccolo  ,

Decisamente il componente TZConnection è più performante del componente TODBCConnection,questo, oltre all'enorme pregio di poter collegare molti DB diversi senza dover poi toccare il codice, ad esclusione della proprietà TZConnection.Databae e Protocol.

Inizialmente avevo erroneamente evidenziato la mancanza, rispetto al componenete TODBCConnection, della possibilità di attribuire direttamente al componente le query CRUD, cosa che obbliga a modificare spesso la proprietà SQL o ad utilizzare un secondo componente TZQuery per le operazioni INSERT, DELETE e UPDATE... mi sbagliavo !

Leggendo il manuale di ZeosLib ho scoperto che TZQuery ha una proprietà chiamata UpdateObject, a cui è possibile assegnare un secondo componente, il TZUpdateSQL a cui a sua volta è possibile assegnare gli script DeleteSQL, UpdateSQL, InsertSQL e RefreshSQL ovviamente parametrizzati ! 

in questo modo, semplicemente con le chiamate myTZQuery.Edit, e myTZQuery.Post, il componente esegue lo script UpdateSQL .... myTZQuery.Delete esegue DeleteSQL .. e così via per gli altri

Fantastico 

[xinyiman]

Ciao giacomoarko, il package TZComponent è un ottimo strumento, occhio solo ad una cosa, non è vero che basta cambiare il protocollo per passare da un database all'altro. Spesso tra i vari dbms cambiano i comportamenti, cambiano le sintassi dei dialetti, ad esempio non tutti ti permettono di fare update se ci sono join nella sintassi della query ecc ecc. Quindi il mio consiglio è se cambi db devi ritestare tutte le funzionalità. Quindi occhio. Se davvero in futuro vuoi fare qualcosa dove l'accesso al db è fortemente astratto ti consiglio di passare tutto da codice e non dai componenti visuali, creare delle unit per tenere separate le singole funzionalità e adottare una strategia di sviluppo TDD (qui una guida al riguardo https://www.lazaruspascal.it/index.php?page=tdd ). Altrimenti non ne esci vivo.

[giacomarko]

Si certamente,

rivedere tutto, e sopratutto ritestare tutto, è un passaggio obbligato, specie dopo un cambiamento di quel genere,

volevo solo dire che poter cambiare protocollo, al posto di sostituire fisicamente tutti i componenti DB, è comunque un bel passo avanti

grazie per il suggerimento