Autor |
Beitrag |
Hänsel
Beiträge: 144
|
Verfasst: Di 10.11.20 08:56
Hallo
ich habe noch Probleme beim der Darstellung von Textfeldern bei eine SQLite-Datenbank.
Ich benutze Delphi 10.1 und habe folgende Komponenten verwendet:
FDConnection FDQuery für die Darstellung der Daten habe ich eine DBGrid verwendet.
Bei allen Textfeldern wird "WideMemo" angezeigt. Kann mir jemand weiterhalfen, so dass ich die Textfelder angezeigt bekomme.
Bei den numerischen Feldern gibt es keine Probleme.
Danke schon mal im Voraus.
Hänsel
|
|
jasocul
Beiträge: 6388
Erhaltene Danke: 146
Windows 7 + Windows 10
Sydney Prof + CE
|
Verfasst: Di 10.11.20 09:16
Du musst die Felder als Varchar und nicht als Text deklarieren.
Da in SQLite der Typ Text "unbegrenzt" ist, wird im DBGrid von einem Memo ausgegangen.
Ich habe keine praktische Erfahrung mit SQLite, gehe aber davon aus, dass Varchar als Typ unterstützt wird.
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 10.11.20 09:26
Ansonsten bliebe noch bei der Abfrage in der TFDQuery ein Cast auf varchar, falls das in der Datenbank ein Textfeld sein muss. Dann wäre aber kein Editieren mehr möglich. Wenn du das Feld editieren möchtest und es ein Textfeld bleiben soll, kannst du ein TDBMemo neben das Grid setzen und dort die Datenquelle (DataSource) und das zu editierende Feld (DataField) setzen.
|
|
Hänsel
Beiträge: 144
|
Verfasst: Di 10.11.20 15:33
Danke für die Hinweise, aber bei SQLite gibt es die Felder "Varchar" nicht.
Vielleicht hat noch jemand dahingehend einen Vorschlag.
Hänsel
|
|
Th69
Beiträge: 4785
Erhaltene Danke: 1055
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Di 10.11.20 16:03
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 10.11.20 17:18
Hänsel hat folgendes geschrieben : | Danke für die Hinweise, aber bei SQLite gibt es die Felder "Varchar" nicht. |
Tut mir leid, das kann ich nicht nachvollziehen. Hier funktioniert das problemlos mit varchar als Datentyp.
Was habe ich gemacht?
- Tabelle angelegt:
SQL-Anweisung 1: 2: 3:
| CREATE TABLE "test" ( "test" VARCHAR ) |
- TFDConnection und TFDQuery auf das Formular, als SQL-Text in der Query SELECT * FROM test eingetragen, Datasource und DBGrid dazu und verdrahtet
- im FormCreate Verbinden und Query aktiv setzen
- Projekt gestartet
Ich hatte sofort die Spalte drin und konnte sie ganz normal editieren.
|
|
jasocul
Beiträge: 6388
Erhaltene Danke: 146
Windows 7 + Windows 10
Sydney Prof + CE
|
Verfasst: Mi 11.11.20 08:16
Ich habe gestern ein bisschen zu SQLite angelesen.
Varchar wird von SQLite zwar als Typ akzeptiert, aber nur aus Kompatibilitätsgründen. Intern ist es trotzdem vom Typ Text. Auch die Längenvorgabe bei varchar wird ignoriert. Und selbst das muss nicht zwingend eine Bedeutung haben, weil der Typ auf Basis des Dateninhalts definiert ist. Wenn ich es richtig verstanden habe, ist z.B. die Zahl 123 in einem Text-Feld trotzdem ein Int aus Sicht von SQLite.
Es kann also im aktuellen Fall auch vom Dateninhalt abhängen. Wenn der Typ allerdings schon als Text definiert ist, ist auch die Vorgabe für das DBGrid eindeutig und wird dort wohl wie ein Memo behandelt. Wäre varchar deklariert worden (mit passender Längenvorgabe), würde es wohl erstmal funktionieren, aber spätestens wenn SQLite meint, dass es zu lang dafür ist oder ein Zeilenumbruch enthalten ist, wird es wohl wieder als Memo dargestellt.
Ich habe mir nicht die Mühe gemacht, dass alles zu prüfen, aber die Doku, die ich dazu im Netz gefunden habe lässt für mich im Moment keinen anderen Schluss zu. Wenn man also varchar(20) deklariert, kann das Feld trotzdem einige tausend Zeichen enthalten. Diese gehen auch nicht verloren. Begrenzungen der Zeichenzahl bleiben komplett in der Verantwortung des Programmierers. In der Datenbank kann das durch Trigger oder Constraints gewährleistet werden.
Keine Ahnung, ob ich dieses System gut oder schlecht finden soll. Es erfordert aber zumindest gute Kenntnisse in SQLite und Sorgfalt bei der Programmierung.
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Mi 11.11.20 09:01
Das ist richtig, aber der Unterschied ist, dass das TDBGrid durch den offiziellen Typ varchar auf die normale Texteingabe geht. Dass das in der Datenbank selber keinen Unterschied macht, ist dabei ja egal.
jasocul hat folgendes geschrieben : | Keine Ahnung, ob ich dieses System gut oder schlecht finden soll. Es erfordert aber zumindest gute Kenntnisse in SQLite und Sorgfalt bei der Programmierung. |
SQLite ist in meinen Augen ähnlich wie PHP:
Es hat sich nicht durchgesetzt, weil es gut ist, sondern weil es da war und die drängendsten Anforderungen unterstützt hat, so dass es schlicht immer häufiger verwendet wurde.
Ich hatte damit auch schon viel "Spaß"...
|
|
jasocul
Beiträge: 6388
Erhaltene Danke: 146
Windows 7 + Windows 10
Sydney Prof + CE
|
Verfasst: Mi 11.11.20 13:49
|
|
Hänsel
Beiträge: 144
|
Verfasst: Mo 16.11.20 15:06
Hallo
danke für Eure Hinweise. Aber ich stehe sicher auf dem Schlauch. Wo wird bzw. an welcher Stelle wird
SQL-Anweisung 1: 2: 3:
| CREATE TABLE "test" ( "test" VARCHAR ) | der Quellcode geschrieben. Denn die Tabelle ist ja schon da.
Gruß
Hänsel
Moderiert von Th69: SQL-Tags hinzugefügt
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Mo 16.11.20 15:59
Das ist der SQL-Quelltext um die Tabelle zu erstellen, das war nur als Beispiel gedacht, weil du meintest, dass es mit varchar nicht geht. Du kannst die bestehende Tabelle natürlich auch ändern.
Wie du varchar getestet hattest, weiß ich ja nicht. Aber ich gehe ja mal davon aus, dass du ein Tool wie SQLiteStudio dafür verwendest. Da gibt es varchar auch direkt als Datentyp.
|
|
Hänsel
Beiträge: 144
|
Verfasst: So 13.12.20 10:20
Danke für die Hinweise, habe mich jetzt für SQLite-Studio entschieden und da funktioniert mein angesprochenes Problem gut.
Hänsel
|
|