Typisierte Dateien nicht möglich?

[mkinzler]

Zitat:

Zitat von greenmile (Beitrag 1260133)

Ich löse es jetzt in dem Fall anders. Habe mir, völlig ab davon, wegen einem anderen Projekt mal SQLITE angeschaut. Es gibt allerdings vier Fragen oder Punkte, über die ich gestolpert bin:
- Was muss ich an DLL's mitgeben? Die SQLITE3.DLL auf Windows Systemen ins Programm-Verzeichnis? Und bei Android/iOS/MacOS?

Bei iOS/Android/MacOSX ist das in das OS integriert.

Zitat:

- Wie kann ich eine einmal definierte Tabelle im Designer (Delphi IDE, Menü "Ansicht" / "Daten-Ansicht") erweitern? Ich habe ein Feld vergessen und die DB ist noch leer ...
- Wo definiere ich im Designer (Delphi IDE, Menü "Ansicht" / "Daten-Ansicht") die Länge eines Text-Feldes?
- Wo definiere ich im Designer (Delphi IDE, Menü "Ansicht" / "Daten-Ansicht"), dass es sich z.B. um ein BOOL Feld handelt?Oder geht das nur mit externen Tools? Oder nur mit SQL? Oder garnicht?

Am Besten mit einem externen Tool. Wobei es egal ist, ob die Tabelle leer ist. Per SQL (ALTER) ist es aber auch möglich die Struktur zu ändern. Über die IDE habe ich das bisher noch nicht versucht ( und gerade auch keine zur Hand, um es zu Testen)

https://addons.mozilla.org/de/firefo...qlite-manager/
http://sqliteadmin.orbmu2k.de/

[Dejan Vu]

Vielleicht zum Verständnis: Es handelt sich nicht um code first, bei dem man in Delphi die Daten/Tabellenstruktur vorgibt und die Feldnamen und Datentypen definiert, sondern um database first*, wobei man, wie schon erwähnt, die Datenstruktur in der Datenbank anlegt, verwaltet und verändert und Delphi diese Strukturen nur übernimmt. Du kannst allerdings mit ein paar Tricks aus z.B. einen Bool-Feld in der DB ein String- oder Integer-Feld in Delphi machen, aber wozu?

(*) Die beiden Begriffe stammen ursprünglich aus dem EF-Umfeld (C# ORM), passen also nicht 100%.

[greenmile]

Zitat:

Zitat von Dejan Vu (Beitrag 1260135)

Vielleicht zum Verständnis: Es handelt sich nicht um code first, bei dem man in Delphi die Daten/Tabellenstruktur vorgibt und die Feldnamen und Datentypen definiert, sondern um database first*, wobei man, wie schon erwähnt, die Datenstruktur in der Datenbank anlegt, verwaltet und verändert und Delphi diese Strukturen nur übernimmt. Du kannst allerdings mit ein paar Tricks aus z.B. einen Bool-Feld in der DB ein String- oder Integer-Feld in Delphi machen, aber wozu?

Ist klar dass man sich vorher Gedanken machen sollte, aber manchmal muss man im Projekt noch etwas ändern, hinzufügen etc. Kommt hin und wieder mal vor :-D. Herr Lehrer.

@mkinzler: Danke.

[Dejan Vu]

Zitat:

Zitat von greenmile (Beitrag 1260138)

Herr Lehrer.

Ich dachte, ich wäre dein potentieller Azubi.
Das sollte im Übrigen nicht belehrend wirken, sondern dem allgemeinen Verständnis dienen. Wenn Du fragst, wo Du in Delphi die Datentypen der Felder ändern musst, darf man ja doch erklärend auf das Grundprinzip eingehen, da die Wahrscheinlichkeit besteht, das hier ein Wissensdefizit besteht.

[greenmile]

Zitat:

Ich dachte, ich wäre dein potentieller Azubi.

Mist, vergessen, Sorry :)

Nein im Ernst, ich muss Altdaten übernehmen und bin im ersten Schritt davon ausgegangen, dass es im SQLLITE keine Bool Felder gibt. Im zweiten Schritt habe ich dann lernen müssen, dass nur die Delphi IDE die Bool's nicht kennt. Da hat sich mir die Frage gestellt: Was passiert, wenn ich in 1 Jahr die Datenbank mal erweitern muss; muss ich es dann mit SQL machen? Oder wenn ich im Laufe des Projekts merke, dass mir 2 Felder fehlen ... Muss ich dann alles von vorne designen? Daher die Frage.

Kurzum: Man braucht nur einen SQLLite Manager. Davon gibt es leider nicht ganz so viele kostenlos, muss mir die erstmal anschauen.

[mkinzler]

Zitat:

wenn ich in 1 Jahr die Datenbank mal erweitern muss; muss ich es dann mit SQL machen?

Wenn das Programm schon deployed ist, wäre dies eine gute Option.
Anderst als bei typisierten Dateien ist die Änderung in der Struktur jederzeit problemlos möglich.

[greenmile]

Zitat:

Zitat von mkinzler (Beitrag 1260149)

Wenn das Programm schon deployed ist, wäre dies eine gute Option.
Anderst als bei typisierten Dateien ist die Änderung in der Struktur jederzeit problemlos möglich.

Deswegen würde ich das anstelle XML in einem anderen Projekt nehmen. Typisierte Dateien verwende ich immer und nur dann, wenn sich definitiv nix mehr ändert. Bei einer Kundendatenbank macht das natürlich wenig Sinn.

[Perlsau]

Zitat:

Zitat von greenmile (Beitrag 1260156)

Typisierte Dateien verwende ich immer und nur dann, wenn sich definitiv nix mehr ändert.

Ich verwende typisierte Dateien nur dann, wenn ich Beispielprogramme für Anfänger zusammenstelle.

[greenmile]

Der kam gut ... ;)

Also, die ersten Schritte in SQLite und ein wenig Schock, INSERT ist sehr langsam. Ich füge in einer Schleife 600 Werte ein, das dauert ca. 5-6 Sekunden (Intel i7, Samsung SSD, also alles schnell genug). Mit Transactions geht es bedeutend schneller (IsolationLevel := xilREADCOMMITTED), aber: Ist das korrekt?

[Bernhard Geyer]

Zitat:

Zitat von greenmile (Beitrag 1260171)

Der kam gut ... ;)

Also, die ersten Schritte in SQLite und ein wenig Schock, INSERT ist sehr langsam. Ich füge in einer Schleife 600 Werte ein, das dauert ca. 5-6 Sekunden (Intel i7, Samsung SSD, also alles schnell genug). Mit Transactions geht es bedeutend schneller (IsolationLevel := xilREADCOMMITTED), aber: Ist das korrekt?

Könnte schon sein. IN meinen Test war SQLite nicht gerade ein Wunter an Geschwindigkeit.
Verwendest du auch prepared Statements?