Typisierte Dateien nicht möglich?

[greenmile]

Hallo,

ich bin gerade dabei, testhalber einige kleinere Anwendungen auf Firemonkey zu portieren um zu testen, inwiefern FM inzwischen produktiv einsetzbar ist.

Unter Windows verwende ich typisierte Dateien:

Code:

Type
  TIrgendwas = Record
    Text1: String[25];
  End;

var Testdatei: File of TIrgendwas;

Beim compilieren bekomme ich unter FM/Android jedoch die Fehlermeldung "; erwartet, [25] gefunden". Funktioniert das so unter FM / Android nicht?

[mkinzler]

Der neue LLVM basierte Compiler kenntz keine ShortStrings

http://docwiki.embarcadero.com/RADSt...om_Desktop_aus

[greenmile]

Ok, aber was verwende ich bei typisierten Dateien dann? Ich muss ja eine String-Länge definieren.

[mkinzler]

In dem Artikel wir Array Of Char vorgeschlagen oder halt RawByteStrings:

http://andy.jgknet.de/blog/2013/10/t...-byte-strings/

[greenmile]

Grmmmpff.
Danke für die Info

[himitsu]

LongStrings und dymanische Arrays ja, dann aber nicht mehr in einem Record. :!:

Du kannst maximal ein statisches Char-Array in den Record packen und über Record-Methoden/Property einen Stringzugriff darauf implementieren.

Oder du steigst auf Datenobjekte um und bastelst dir dafür entsprechende Speicherroutinen (hier kannst du z.B. auch TReader/TWreiter verwenden)
oder du nimmst persistente Datenopjekte und probierst es mit den entsprechenden Serialisierungsfunktionen der Streams, bzw. direkt über TReader/TWriter.

[jaenicke]

Wobei ich Klassen mit entsprechenden Stream-Funktionen usw. oder Datenbanken ohnehin für deutlich sauberer halte als die typisierten Dateien, die aus einer Zeit stammen als das eben nicht sinnvoll anders ging...

[greenmile]

Ziel ist es, ca. 600 Datenblöcke einer fest definierten Größe (String, Integer, Bool usw.) mehrfach auf einem Mobile-Device zu speichern. XML scheidet daher wg Overhead aus, ich denke das wird zuviel Speicher fressen. Eine Datenbank scheint mir Overkill. Was schlagt ihr vor?

[mkinzler]

Zitat:

Eine Datenbank scheint mir Overkill.

Warum?
iOS und Android unterstützen beide SQLite und Delphi XE5+XE6 beinhalten zudem IBLite für die beiden Plattformen.

[greenmile]

Geht also nicht?

[Zoot]

Warum keinen Stream?

[greenmile]

Hast Du ein Beispiel?

[p80286]

Zitat:

Zitat von greenmile (Beitrag 1259958)

Ziel ist es, ca. 600 Datenblöcke einer fest definierten Größe (String, Integer, Bool usw.) mehrfach auf einem Mobile-Device zu speichern. XML scheidet daher wg Overhead aus, ich denke das wird zuviel Speicher fressen. Eine Datenbank scheint mir Overkill. Was schlagt ihr vor?

Ausprobieren!
wenn Du der Datenbank alles nimmst (benutzerverwaltung, indizes...) was sie zur Datenbank macht, sollte sie auch relativ klein sein.

Eine weitere Möglichkeit wäre CSV.

Gruß
K-H

[himitsu]

Wie gesagt, wenn es unbedingt binär sein muß, dann musst du entweder die ShortStrings auf statische Char-Arrays ändern und eventuell noch umkopierfunktionen für die Strings bereitstellen,
oder du mußt auf Datenobjekte umsteigen, welche dann in einen Stream serialisiert werden.

Man kann auch alle 600 Blöcke in einem zug speichern/laden, wenn man das als Objekt-Liste (am Besten als TCollection) verwaltet.

Für Collections, oder zumindestens für TPersistent-Datenobjekte, gibt es im Delphi bereits fertige (De)Serialisierungsmethoden.

[Dejan Vu]

Warum sollte man sich heutzutage bei Basics wie 'Daten speichern/lesen' noch mit irgendwelchen selbstgefrickelten Lösungen herumschlagen? Freunde dich mit den unterstützten Datenbanken an oder verwende eben XML oder JSON, so schlimm ist das doch nicht. Natürlich kann man sparen, aber doch nicht unbedingt hier.

Da Du dich sowieso früher oder später mit den Datenbanken und Standardformaten beschäftigen musst, warum nicht gleich jetzt schon?

Zitat:

Zitat von p80286 (Beitrag 1259963)

Eine weitere Möglichkeit wäre CSV.

Würde ich nicht machen, auch wenn es eine weitere Möglichkeit wäre (wie SYLK auch). Aber wozu. Stick to the Standard.

[Stevie]

Die 80er haben angerufen, sie wollen ihre typed files wieder. :lol:

Aber mal Scherz beiseite, ich kann das als jemand sagen, der in der Vergangenheit schon so manches mal über Delphi Code geflucht hat, der einfach irgendwelche Strukturen in solch einer Form gespeichert hat. Seien es file of irgendwas oder in Streams gehämmerte Daten. Damit handelt man sich nämlich nur Probleme ein, wenn man mal was erweitert oder ändert.

[Dejan Vu]

Zitat:

Zitat von Stevie (Beitrag 1259982)

Die 80er haben angerufen, sie wollen ihre typed files wieder. :lol:

Diese Äußerung verursachte eine spontane Befeuchtung meiner Monitore infolge stoßartig entstandenen Sprühnebels.

Vielen Dank. :-D

[greenmile]

Nun ja ... meinst Du nicht dass ich sehr genau weiss, was ich tue? Ich bin etwas länger in der Programmierung und stamme noch aus einer Zeit, in der man sich Gedanken zur Optimierung und Speicherbedarf gemacht hat. Eine SQL Datenbank zu installieren, nur um einige Daten zu speichern, ist halt Overhead. Noch mehr Overhead hat, auch wenn es sicherlich seine Vorteile hat, XML. Ich brauche diesen Overhead in diesem Punkt (um den es hier geht) ganz einfach nicht, es wäre wie Kanonen auf Spatzen schießen; und ich gehöre zu den Menschen die sich relativ genau anschauen, wie groß eine App ist und ob die Größe wirklich Sinn macht. Typisierte Dateien haben sicherlich Nachteile, aber was den effektiven Speicherbedarf angeht sind sie wahrlich nicht zu toppen. Kann man ignorieren, ist aber so. Und das hat nun nichts mit den 80'ern zu tun.

BTW: Ich liebe Diskussionen in denen man etwas erfragt und man als Antwort von einigen Usern zu hören bekommt, wie old-school man ist und wie falsch man doch liegt. Statt einfach eine Lösung zu schreiben oder schlichtweg nicht zu antworten. Sonst würdet ihr ja auch Visual Studio + SQL Server Express nutzen, oder?

[Stevie]

Zitat:

Zitat von greenmile (Beitrag 1259991)

BTW: Ich liebe Diskussionen in denen man etwas erfragt und man als Antwort von einigen Usern zu hören bekommt, wie old-school man ist und wie falsch man doch liegt. Statt einfach eine Lösung zu schreiben oder schlichtweg nicht zu antworten. Sonst würdet ihr ja auch Visual Studio + SQL Server Express nutzen, oder?

Ich will hier keine Diskussion über Old-school oder nicht starten und ob man auch mal Dinge, die "man schon immer so gemacht hat" auch weiter tun sollte (mein Chef sagt bei solchen Gelegenheiten immer "früher haben wir auch Hexen verbrannt und dann irgendwann damit aufgehört") - aber deine Reaktion schürt so ein bisschen das Vorurteil, was du zu dementieren versuchst.

Daher mal zum Thema zurück, du weißt, dass es Dinge wie SQLite gibt, wo man nix installieren muss, um eine Datenbank zu haben, in die man so ziemlich alles reinstopfen kann, wozu man lustig ist. Heute sind die miesesten Smartphones schneller als die Server von anno dazumal, wo man für alle seine Resourcen zusammen kratzen musste. Das vergessen nämlich auch einige (und nein, ich sagte nicht, dass man mit seinen Resourcen sorglos um sich werfen sollte)

[Sir Rufo]

SQLite ist ein absolut legitimer Vorschlag, denn auch wenn du damit nicht arbeiten möchtest, ist es trotzdem auf den Geräten schon vorhanden. Es ist ein fester Bestandteil der Systeme (Android/iOS).

Du musst also nur sagen "Ja, ich will" und kannst ohne zusätzlichen Ballast damit arbeiten.

Somit ist dein Einwand "SQL Datenbank installieren" hinfällig, denn ohne gibts das nicht, es ist einfach da, so wie auch das Display einfach da ist ;)

[greenmile]

Zitat:

Zitat von Sir Rufo (Beitrag 1259998)

SQLite ist ein absolut legitimer Vorschlag, denn auch wenn du damit nicht arbeiten möchtest, ist es trotzdem auf den Geräten schon vorhanden. Es ist ein fester Bestandteil der Systeme (Android/iOS).

Cool, das wusste ich jetzt wirklich noch nicht.

[Dejan Vu]

Um das vielleicht noch einmal klarzustellen: Man kann sich Gedanken machen. Und man kann sich überflüssige Gedanken machen. Meist macht man das in dieser Reihenfolge.

Zitat:

Zitat von greenmile (Beitrag 1259991)

Nun ja ... meinst Du nicht dass ich sehr genau weiss, was ich tue? Ich bin etwas länger in der Programmierung

... Ehrlich gesagt, wenn Du so direkt fragst: Nein. Wenn Du wirklich lange genug bei der Programmierung wärst, dann hätte Dir auffallen müssen, das sich die Erde weitergedreht hat und man sich darüber nicht unbedingt mehr Gedanken macht, zumal man auf dieser Ebene auch nicht mehr programmiert (normalerweise).

Aber darum ging es nicht und darum geht es nicht. Es geht darum, die Standardwerkzeuge zu verwenden, die einem die Umgebung, in der man und für die man programmiert, bietet. Meist wissen Programmierer nicht, was Standard ist, weil sich sich nicht diesbezüglich schlau machen oder einfach meinen, alles selbst machen zu müssen. Aber das Allerwichtigste, wenn man sich in einem neuen Umfeld bewegt ist doch die Beantwortung der Fragen: "Wie machen das die Anderen?", "Was ist Stand der Technik?", "Was ist usus?" Wenn diese Fragen beantwortet sind, kann man ja immer noch entscheiden, ob man seinen eigenen Weg geht, oder Standards verwendet.

Und abschließend: Nichts von dem ist böse gemeint oder auf Angriff gebürstet, auch wenn es direkt ist. Schönes Wochenende. :)

[greenmile]

Belassen wir es besser dabei. Bitte repektiere, wenn manche Menschen manche Probleme anders lösen. Es ist mitunter nicht schlechter, nicht besser, sondern einfach anders und manchmal denken sich diese Menschen etwas dabei.

[sx2008]

Ich muss hier auch mal in die gleiche Kerbe hauen :-)
Typisierte Dateien, also Dateien mit fester Satzstruktur sind eine Sackgasse :!:
Das wurde schon vor 1980 erkannt als das dBase-Format entwickelt wurde.
dBase-Dateien haben im Prinzip eine feste (aber änderbare) Satzstruktur nur dass sich davor noch ein Header befindet der jedes einzelne Datenfeld (Name, Datentyp und ggf. noch Länge oder Nachkommastellen) maschinenlesbar erklärt.
Die zweite geniale Idee von dBase ist jeden Datensatz grundsätzlich mit einem Delete-Flag auszustatten damit man Datensätze (=Records) löschen kann ohne die ganze Datei neu erzeugen zu müssen.
dBase hat damit den Mindeststandard für tabellenartige Dateien gesetzt.
Darunter kommt als akzeptables Format nur noch CSV (und eigentlich ist das nur ein Datenaustauschformat und kein Datenformat mit dem man effizient arbeiten kann).

SQLite hat sich vom Spielzeug zu einem ausgereiften Datenspeicher entwickelt.
Der Overhead liegt pro SQLite-Datei bei ca 220kB und ca. zusätzlichen 400kB Programmcode (wenn der SQLite-Code statisch gelinkt wird).
Wenn du nach typisierten Dateien fragst ist das ungefähr so als ob du Infos über Waschbretter haben möchtest obwohl es seit Jahrzehnten gute Waschmaschinen gibt :-)

Noch ein Tipp zu SQLite:
Hol dir den SQLite Manager für den Firefox Browser - damit kannst du SQLite Dateien perfekt anlegen, ändern, untersuchen, usw.

@greenmile: sorry aber ich hatte meinen Beitrag schon fertig und manchmal muss man eben was loswerden

[mkinzler]

Zitat:

Zitat von greenmile (Beitrag 1260001)

Zitat:

Zitat von Sir Rufo (Beitrag 1259998)

SQLite ist ein absolut legitimer Vorschlag, denn auch wenn du damit nicht arbeiten möchtest, ist es trotzdem auf den Geräten schon vorhanden. Es ist ein fester Bestandteil der Systeme (Android/iOS).

Cool, das wusste ich jetzt wirklich noch nicht.

http://www.delphipraxis.net/1259959-post9.html

[Mavarik]

Zitat:

Zitat von greenmile (Beitrag 1259915)

Hallo,

Delphi-Quellcode:

Type
  TIrgendwas = Record
    Text1: String[25];
  End;

Nimm einfach

Delphi-Quellcode:

Type
  TIrgendwas = Record
    Text1: Array[0..25] of Byte;
  End;

Fertig...

[Dejan Vu]

Seufz:
http://www.delphipraxis.net/1259922-post1.html

[himitsu]

Wieso Byte?
Ich denk dort soll ein String rein, mit vielen Chars. ;)

Delphi-Quellcode:

type
  TMyRecord = record
    MyInteger: Integer;
    _MyString: array[0..24] of AnsiChar;  // UTF8-codiert
    ...
  private
    function  GetMyString: string;  // hier drin UTF8Encode/UTF8Decode und die Zuweisung an/von _MyString
    procedure SetMyString(Value: string);
  public
    property MyString: string read GetMyString write SetMyString;
  end;

Delphi-Quellcode:

type
  TMyRecord = record
    MyInteger: Integer;
    _MyString: array[0..24] of Char;
    ...
  private
    function  GetMyString: string;  // hier drin die Zuweisung an/von _MyString
    procedure SetMyString(Value: string);
  public
    property MyString: string read GetMyString write SetMyString;
  end;

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1260074)

Wieso Byte?

Wer spricht hier von Bytes? Der Link im Link? Es werden dort alle Möglichkeiten aufgezeigt, einen ShortString zu ersetzen und dazu gehört neben dem Array of Char eben auch RawBytes, wobei ich letzteres vorziehe, weil ich neuerdings bei 'Char' immer an 'Zeichensätze' und 'Konvertierung' denke. Muss nicht sein, aber bei 'RawBytes' denke ich nicht daran.

[greenmile]

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?
- 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?

[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?