Problemi con i componenti (database) standard di lazarus

[xinyiman]

Ciao ragazzi, ho bisogno d'aiuto con i componenti standard dei database di lazarus. Per anni ho usato zeoslib ma ora per un altro progetto voglio usare i componenti standard.
Vi allego un esempio che si appoggia ad un database sqlite

Primo problema : se quando compare la griglia con i dati voi fate tasto destro sulla griglia e gli dite "Insert a new line" compare una nuova finestra che vi permette di aggiungere un record.
Compilate i dati e poi date "save"

Vedrete che il programma va in errore perchè dice che la tabella nel database non contiene il campo "category". Questo è vero perchè si tratta di un campo fklookup aggiunto sul dataset per rendere graficamente utilizzabile la griglia. Come faccio a salvare dicendogli di ignorare quel campo?

Secondo problema : se compilate il progetto cambiando le custom options da

-dNoRefreshAfterInsert
-dNoRefreshAfterEdit
-dNoRefreshAfterDuplicate
-dNoRefreshAfterDelete
-dNoActualRowPosition


a

-dRefreshAfterInsert
-dRefreshAfterEdit
-dRefreshAfterDuplicate
-dRefreshAfterDelete
-dActualRowPosition

e provate ad inserire un nuovo record o a modificarne uno esistente vedrete che il programma va in errore a causa del TBookMark che non fa più riferimento ad un dato valido dopo il refresh. Questo è stranissimo perchè con zeos funziona benissimo.

[tito_livio]

Ciao Xiniyman,
succede la stessa cosa con i campi calcolati che, ovviamente, non esistono nella tabella nel database.
Credo quindi che tu debba modificare una propritetà del campo "category".
La proprietà è ProviderFlags per cui deve essere pfIUpdate=false.
Ti allego un'immagine per spiegarmi meglio.
Spero ti sia d'aiuto.

[xinyiman]

Grazie, proverò quanto prima.

[xinyiman]

Ciao, funziona alla grande. Invece per quanto riguarda il bookmark hai idee?

[tito_livio]

Per la seconda domanda ci sto pensando, ti facco sapere quanto prima.
Ciao.

[tito_livio]

Dovresti provare a cambiare la proprietà UpdateMode (di Q_Grid_table_test) da upWhereKeyOnly in upWhereChanged.
Ti dico provare perchè ho delle difficoltà nel gestire il progetto di esempio, spero che comunque il suggerimento ti sia utile.
Ciao.

[xinyiman]

Ecco una versione funzionante.

[Avogadro]

Posto qui una domanda.

Premessa:

Sto usando sqlite e zeoslib (e rxdbgrid) in una applicazione di office automation, niente di che, devo dare un ordine dei dati da cui poi ricavare una parcella o un preventivo.

Ho necessità di gestire stringhe lunghe piu' di 254 caratteri senza pero' passare per le forche caduine della loro gestione con lo strumento "memo" e tutte le manovre necessarie per farle apparire nella bgrid - confesso il peccato, non riesco a concepire un sw senza una dbgrid/grid  , sara' la'bitunid e(o effetto ancoraggio), ma tant' è -.

Ora che dimensioni ha la stringa massima che si puo' gestire in un campo (filed)  con l' abbinata lazarus-zeoslib-sqlite ?

In Sqlite  in ogni caso bisogna dichiarare la lunghrzza della stringa affinché poi zeoslib la processi correttamente.


Grazie anticipate

Ciao

[xinyiman]

Ciao Avogadro. Sarebbe sempre meglio aprire nuovi 3d per argomenti diversi.

Allora, devi dichiarare il tipo come un varchar(lunghezza_massima). Per la massima dimensione basta guardare la fonte ufficiale.

http://www.sqlite.org/limits.html

Codice: [Seleziona]

    Maximum length of a string or BLOB

    The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000). You can raise or lower this value at compile-time using a command-line option like this:

    -DSQLITE_MAX_LENGTH=123456789 The current implementation will only support a string or BLOB length up to 231-1 or 2147483647. And some built-in functions such as hex() might fail well before that point. In security-sensitive applications it is best not to try to increase the maximum string and blob length. In fact, you might do well to lower the maximum string and blob length to something more in the range of a few million if that is possible.

    During part of SQLite's INSERT and SELECT processing, the complete content of each row in the database is encoded as a single BLOB. So the SQLITE_MAX_LENGTH parameter also determines the maximum number of bytes in a row.

[Avogadro]

Non mi sembrava il caso di fare un altro 3ad, ma ormai è andata così .

Allora: è noto che sqlite  puo' gestire stringhe grandi quanto si vuole, ma io ho posto un'altra questione: con gli strumenti lazarus+zeoslib+sqlib si possono gestire campi stringa aventi piu' di 255 caratteri senza passare per le forche caduine  dei memo ?

Pare di no, almeno a quanto dicono qui:

https://forum.lazarus.freepascal.org/index.php?topic=37544.0

Quel che chiedo se ci sono state nel tempo delle modifiche per poter gestire in una dbgrid campi stringa con piu' di 255 caratteri.

Sto usando rxdbgrid che offre le possibilità di avere righe di altezza variabile in funzione della lunghezza del teso ed esportare in xls, pdf o stampare direttamente senza passare per le forche caduine di lazfreport.


Tutto qui

[xinyiman]

Scusa Avogadro, avevo frainteso la domanda. Che io sappia bisogna per forza passare dalla memo. In pratica il concetto è.

Inserisco una memo nella form con visible = false.

Poi nell'evento SelectEditor della griglia sposto la memo sulla cella che voglio editare, la faccio diventare visibile.

Gestisco il cambio di stringa con gli eventi della memo. Quando esco dalla memo la rendo nuovamente invisibile.

[Avogadro]

Si, mi sono già cimentato con questo approccio e mio malgrado lo dovro' adottare.

Sotto delphi era piu' semplice, ma tant'è .

Ciao e grazie

[xinyiman]

Io personalmente sono giunto ad una conclusione.

Non uso più la dbgrid. Mi sono realizzato una mia stringgrid modificata. Praticamente gli passo il dataset e lei disegna il contenuto del dataset. Poi per la modifica dei dati sul doppio click apro una finestra che contiene i controlli per la modifica del singolo record.
Alla fine mi risolve tanti mal di pancia.

[Avogadro]

Anch'io o usato un approccio analogo: pur non abbandonando la dbgrid l'edit dei dati lo faccio in un form ad hoc .

Diciamo che il problema è l' effetto ancoraggio: ho iniziato con delphi e il suo dbengine (BDE mi pare) che si poggiava su paradox  ed era relativamente semplice gestire le varie situazioni (campi meno ed rft, immagini etc) .

Poi il marketing ha decretato la fine di questo approccio, ho provato con ODBC ed Access ma c'erano problemi continui: bisognava ricorre all' sql,   configurare le macchine   etc; il guaio finale fu che ad un certo punto, con le nuove versioni di lazarus  il sistema che si poggiava su Access non funzionava piu' .

Ho provato poi con DBF ma con l'aumentare del numero di record la lentezza era insostenibile.

Tornando alla dbgrid da qualche parte ho letto  che non è la scelta d'elezione per le interfacce, specialmente per i lavori in remoto;  io comunque sono abituato a vedere l' insieme dei dati  e mi sento a disagio se il sw mi fa vedere solo un record per volta - ricordo un applicazione per l' invio di certi dati in remoto, la gente si rifiutava di usarla  perchè bisognava editare un record  alla volta e poi mandarlo; adesso l' hanno modificata facendo creare degli xml con excel e le cose vanno meglio, solo che normalizzazione ansi sql è andata a farsi benedire  - .

   

[Stilgar]

Forse, la butto lì, avere una griglia con i dati di "base" che diano l'idea di che record si sta parlando e una form dedicata con tutti i dettagli?Al posto della db grid puoi usare un VirtualTree per la gestione dei dati "sinottici".

Questo è l'approccio di HeidiSql. (Scritto in Delphi)

https://github.com/HeidiSQL/HeidiSQL
Stilgar