* * * *

Privacy Policy

Forum ufficiale

Se non siete riusciti a reperire l'informazione che cercavate nei nostri articoli o sul nostro forum vi consiglio di visitare il
Forum ufficiale di Lazarus in lingua inglese.

Lazarus 1.0

Trascinare un file nel programma
DB concetti fondamentali e ZeosLib
Recuperare codice HTML da pagina web
Mandare mail con Lazarus
Stabilire il sistema operativo
Esempio lista in pascal
File INI
Codice di attivazione
Realizzare programmi multilingua
Lavorare con le directory
Utilizzare Unità esterne
TTreeView
TTreeview e Menu
Generare controlli RUN-TIME
LazReport, PDF ed immagini
Intercettare tasti premuti
Ampliare Lazarus
Lazarus e la crittografia
System Tray con Lazarus
UIB: Unified Interbase
Il file: questo sconosciuto
Conferma di chiusura di un applicazione
Liste e puntatori
Overload di funzioni
Funzioni a parametri variabili
Proprietà
Conversione numerica
TImage su Form e Panel
Indy gestiore server FTP lato Client
PopUpMenu sotto Pulsante (TSpeedButton)
Direttiva $macro
Toolbar
Evidenziare voci TreeView
Visualizzare un file Html esterno
StatusBar - aggirare l'errore variabile duplicata
Da DataSource a Excel
Le permutazioni
Brute force
Indy 10 - Invio email con allegati
La gestione degli errori in Lazarus
Pascal Script
Linux + Zeos + Firebird
Dataset virtuale
Overload di operatori
Lavorare con file in formato JSON con Lazarus
Zeos ... dietro le quinte (prima parte)
Disporre le finestre in un blocco unico (come Delphi)
Aspetto retrò (Cmd Line)
Lazarus 1.0
Come interfacciare periferica twain
Ubuntu - aggiornare free pascal e lazarus
fpcup: installazioni parallele di lazarus e fpc
Free Pascal e Lazarus sul Raspberry Pi
Cifratura: breve guida all'uso dell'algoritmo BlowFish con lazarus e free pascal.
Creare un server multithread
guida all'installazione di fpc trunk da subversion in linux gentoo
Indice
DB concetti fondamentali e connessioni standard
Advanced Record Syntax
DB concetti fondamentali e DBGrid
DB concetti fondamentali e TDBEdit, TDBMemo e TDBText
Advanced Record Syntax: un esempio pratico
Superclasse form base per programmi gestionali (e non)
Superclasse form base per programmi gestionali (e non) #2 - log, exception call stack, application toolbox
Superclasse form base per programmi gestionali (e non) #3 - traduzione delle form
Superclasse form base per programmi gestionali (e non) #4 - wait animation
Un dialog per la connessione al database:TfmSimpleDbConnectionDialog
Installare lazarus su mac osx sierra
immagine docker per lavorare con lazarus e free pascal
TDD o Test-Driven Development
Benvenuto! Effettua l'accesso oppure registrati.
Agosto 09, 2020, 07:06:47 am

Inserisci il nome utente, la password e la durata della sessione.

21 Visitatori, 0 Utenti

Autore Topic: Problemi con i componenti (database) standard di lazarus  (Letto 2944 volte)

xinyiman

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Problemi con i componenti (database) standard di lazarus
« il: Dicembre 02, 2019, 11:25:49 am »
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.
Ieri è passato, domani è futuro, oggi è un dono...

tito_livio

  • Newbie
  • *
  • Post: 13
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #1 il: Dicembre 03, 2019, 01:16:04 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #2 il: Dicembre 03, 2019, 01:33:44 pm »
Grazie, proverò quanto prima.
Ieri è passato, domani è futuro, oggi è un dono...

xinyiman

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #3 il: Dicembre 04, 2019, 11:44:03 pm »
Ciao, funziona alla grande. Invece per quanto riguarda il bookmark hai idee?
Ieri è passato, domani è futuro, oggi è un dono...

tito_livio

  • Newbie
  • *
  • Post: 13
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #4 il: Dicembre 06, 2019, 11:25:30 am »
Per la seconda domanda ci sto pensando, ti facco sapere quanto prima.
Ciao.

tito_livio

  • Newbie
  • *
  • Post: 13
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #5 il: Dicembre 09, 2019, 07:19:56 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #6 il: Dicembre 09, 2019, 09:08:31 pm »
Ecco una versione funzionante.
Ieri è passato, domani è futuro, oggi è un dono...

Avogadro

  • Full Member
  • ***
  • Post: 140
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #7 il: Gennaio 13, 2020, 09:36:57 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #8 il: Gennaio 15, 2020, 01:43:57 pm »
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.
Ieri è passato, domani è futuro, oggi è un dono...

Avogadro

  • Full Member
  • ***
  • Post: 140
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #9 il: Gennaio 15, 2020, 05:33:12 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #10 il: Gennaio 16, 2020, 08:34:18 am »
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.
Ieri è passato, domani è futuro, oggi è un dono...

Avogadro

  • Full Member
  • ***
  • Post: 140
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #11 il: Gennaio 16, 2020, 02:15:31 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Post: 2869
  • Karma: +9/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #12 il: Gennaio 16, 2020, 04:41:43 pm »
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.
Ieri è passato, domani è futuro, oggi è un dono...

Avogadro

  • Full Member
  • ***
  • Post: 140
  • Karma: +0/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #13 il: Gennaio 16, 2020, 08:21:48 pm »
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  - .

   




« Ultima modifica: Gennaio 16, 2020, 08:24:08 pm da Avogadro »

Stilgar

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2121
  • Karma: +6/-0
Re:Problemi con i componenti (database) standard di lazarus
« Risposta #14 il: Gennaio 17, 2020, 09:26:40 am »
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
Al mondo ci sono 10 tipi di persone ... chi capisce il binario e chi no.

 

Recenti

How To

Utenti
  • Utenti in totale: 680
  • Latest: bernisim
Stats
  • Post in totale: 13806
  • Topic in totale: 1730
  • Online Today: 36
  • Online Ever: 900
  • (Gennaio 21, 2020, 08:17:49 pm)
Utenti Online
Users: 0
Guests: 21
Total: 21

Disclaimer:

Questo blog non rappresenta una testata giornalistica poiché viene aggiornato senza alcuna periodicità. Non può pertanto considerarsi un prodotto editoriale ai sensi della legge n. 62/2001.