mp-one hat geschrieben:Die DB ist momentan in Access gemacht und könnte dann leicht nach Excel und CSV konvertiert werden, um sie in den ATARI zu bekommen.

Kleiner Tip: Mach einen riesen Bogen um MS Office wenn's um den CSV Export geht. Ich hatte da gerade eben die "lustigsten" Probleme bei einem Projekt. Mit OpenOffice (das die Excel Dateien ja problemlos lesen kann) klappte der CSV Export so wie er sollte, aber Excel und Access bekamen einfach keine korrekten CSV Dateien hin.

Noch ein Tip: OpenOffice lässt sich problemlos parallel zu MS Office installieren, es fragt sogar bei der Installation explizit nach ob man es nur mal ausprobieren will - xls, doc & co bleiben dann weiterhin mit MS Office verknüpft.

so long,

Hias

HiassofT hat geschrieben:

mp-one hat geschrieben:Die DB ist momentan in Access gemacht und könnte dann leicht nach Excel und CSV konvertiert werden, um sie in den ATARI zu bekommen.

Kleiner Tip: Mach einen riesen Bogen um MS Office wenn's um den CSV Export geht. Ich hatte da gerade eben die "lustigsten" Probleme bei einem Projekt. Mit OpenOffice (das die Excel Dateien ja problemlos lesen kann) klappte der CSV Export so wie er sollte, aber Excel und Access bekamen einfach keine korrekten CSV Dateien hin.

Noch ein Tip: OpenOffice lässt sich problemlos parallel zu MS Office installieren, es fragt sogar bei der Installation explizit nach ob man es nur mal ausprobieren will - xls, doc & co bleiben dann weiterhin mit MS Office verknüpft.

so long,

Hias

Hi,

dank' Dir für den Tipp. Es ist zum Glück nur die Datenbank-Datei selbst (*.MDB) im Access-/Office-Format, der Rest (auch der CSV-Export) könnte auch ohne jegliches Office über Delphi laufen und dort kann ich auch manuell eingeifen, falls es nötig ist. Das mit MS- und OpenOffice werd' ich mir aber merken, denn schon beim nächsten Projekt kann's mich auch erwischen .

Michael

Hallo Michael,

Wow!
Sieht schon recht gut aus.

PDN: Sieht schon gut aus, Wichtig: Disknummer+zweistellige Programmnummer, Wäre also bei EGON 101.
PDName: Passt!
PDDesc: Kann man rauskopieren nach dem Konvertieren und getrennt speichern. Lässt sich also auch machen.
Disknummer: Passt!
Genrenummer: Muss man sowieso manuell nachpflegen.
Diskart: Passt / bzw. wäre dann über eine Kennnummer noch zu ersetzen, geht aber auch nach der Umformatierung.
XL: Schon angelegt, kann also leicht in Excel ausgefüllt werden. Super!
DescFilename: Auch schon angelegt, prima. Da kann man dann den Dateinamen der Beschreibung eintragen.

Wichtig ist dann nur noch die Reihenfolge:

11101 ;PDN - Programmnummer
Printmaster ;A$ - Programmname
111 ;N - Disknummer
27 ;GNR - Genrenummer
1 ;XL - Systemanforderungen
D11101 ;DAT$ - Beschreibungsdateiverweis

kann man aber auch noch in Excel umstellen.

Nun nimmt die Sache ja richtig Tempo auf. Schick mir mal deine Mailadresse, dann kann ich dir mal eine csv Datei schicken, die 100 Disks enthält.

Grosses Lob schon mal!


Holger

HiassofT hat geschrieben:

mp-one hat geschrieben:Die DB ist momentan in Access gemacht und könnte dann leicht nach Excel und CSV konvertiert werden, um sie in den ATARI zu bekommen.

Kleiner Tip: Mach einen riesen Bogen um MS Office wenn's um den CSV Export geht. Ich hatte da gerade eben die "lustigsten" Probleme bei einem Projekt. Mit OpenOffice (das die Excel Dateien ja problemlos lesen kann) klappte der CSV Export so wie er sollte, aber Excel und Access bekamen einfach keine korrekten CSV Dateien hin.

Noch ein Tip: OpenOffice lässt sich problemlos parallel zu MS Office installieren, es fragt sogar bei der Installation explizit nach ob man es nur mal ausprobieren will - xls, doc & co bleiben dann weiterhin mit MS Office verknüpft.

so long,

Hias

Da ich eh schon lange auf Linux arbeite, habe ich sowieso Openoffice. Funktioniert problemloser als MS Office, wie ich täglich auf der Arbeit leidvoll miterleben muss.


Gruss, Holger

@mp-one: so ähnlich hätte ich es auch gelöst, allerdings komplett im Office, aber das lässt sich ja leicht sagen, wenn schon einer vorgelegt hat
(allerdings hätten mir noch die Mappingtabellen für das Genre und die Systemanforderungen gefehlt)
@hias: hm, komisch ich arbeite täglich mit office, hatte noch nie ernste Probleme im csv export...

Grundsätzlich sollte man nur darauf achten, dass die Datenbank, auch wieder exportiert werden kann, um sie bspw. leicht in eine web-db importieren zu können.

Holger, Michael, habe euch eine Mail PN geschickt!

eda70 hat geschrieben:@hias: hm, komisch ich arbeite täglich mit office, hatte noch nie ernste Probleme im csv export...

Ich weiss jetzt nicht mehr genau welche Office Version beim Kunden installiert war, aber die Fehler waren gravierend. So grob aus dem Gedächtnis:

- Per Default gibt's ein Semikolon als Feldtrenner (gute Idee für _C_SV...)
- CSV Export unter Excel bot weniger Optionen an als unter Access (?)
- Nach Lust und Laune wurden gewisse Spalten aus Excel/Access ohne Anführungszeichen exportiert.
- Der Hammer war aber, daß die Postleitzahlen mit 2 Kommastellen exportiert wurden, sowohl in Excel, als auch unter Access (bei letzterem unabhängig davon welcher Datentyp für die Spalte verwendet wurde). Konsequenterweise fehlten hier immer die Anführungszeichen. Nach gut 1.5h herumprobieren haben wir dann aufgegeben...

Daheim (und in der Arbeit) Arbeite ich ausschliesslich unter Linux und OpenOffice. Die original Excel Datei liess sich problemlos mit OO öffnen und korrekt als CSV exportieren.

so long,

Hias

CSV heißt auch Character Separated Values, das schließt das Semikolon mit ein.
Über eine Exportspezifikation sollte sich das aber lösen lassen.
<ende>

eda70 hat geschrieben:CSV heißt auch Character Separated Values, das schließt das Semikolon mit ein.

Mööp, falsch :-)

Das "C" steht für "Comma".

so long,

Hias

mööp - frag wikipedia!
Nur das Komma macht ja auch keinen Sinn, da es min. in Deutschland als Dezimaltrennzeichen genutzt wird.
Wäre schon doof, wenn man immer erst alles konvertieren müßte...

eda70 hat geschrieben:mööp - frag wikipedia!
Nur das Komma macht ja auch keinen Sinn, da es min. in Deutschland als Dezimaltrennzeichen genutzt wird.
Wäre schon doof, wenn man immer erst alles konvertieren müßte...

Hm, ich wär' für "Clever Separated Value"

eda70 hat geschrieben:mööp - frag wikipedia! :D

Man soll nicht alles glauben, was auf Wikipedia Seiten steht. Schaue Dir zum Vergleich mal an, was auf en.wikipedia.org steht - das liest sich für mich deutlich präziser und dort wird auch zwischen CSV und allgemeinen "delimiter separated" Formaten unterschieden.

Den Ausdruck "Character separated values" höre ich zum allerersten mal, keine Ahnung woher der kommt.

Grundproblem ist und bleibt aber, daß CSV kein offizieller Standard ist und hier viele Leute viele eigene Süppchen kochen. Deshalb wäre es gut, es nicht einfach irgendwie zu machen sondern so wie im rfc4180 beschrieben.

Ich persönlich habe die besten Erfahrungen damit gemacht, alle Felder immer unter Anführungszeichen zu setzen (laut RFC nicht zwingend vorgeschrieben) und als Trennzeichen eben das Komma zu verwenden.

Nur das Komma macht ja auch keinen Sinn, da es min. in Deutschland als Dezimaltrennzeichen genutzt wird.
Wäre schon doof, wenn man immer erst alles konvertieren müßte...

Das ist kein Problem auf der Ebene des Fileformats (ein Komma kann auch in einem normalen Text vorkommen, zB hier als Beistrich - dann wird das Feld eben unter Anführungszeichen gesetzt) sondern eine Ebene darüber: wie sind die Felder der Datensätze zu interpretieren (Text, Integer, Float, ...). Letzteres wird aber im CSV Format garnicht behandelt (genauso wie die Zeichencodierung) - dafür muss man XML oder ähnliches heranziehen.

BTW: Trenn- und Begrenzungszeichen automatisch zu erkennen ist alles andere als trivial. Im Vergleich dazu ist es schon deutlich einfacher per Heuristiken festzustellen ob es sich bei einem Feld um Text, eine (Integer-) Zahl usw. handelt. Hier kann man im Zweifelsfall einfach beim Benutzer nachfragen. Bei Fragen des Fileformats oder irgendwelcher Trennzeichen sind die meisten Anwender komplett überfordert.

so long,

Hias

HiassofT hat geschrieben:Schaue Dir zum Vergleich mal an, was auf en.wikipedia.org steht...

Nun das wundert mich nicht. Benutzen doch die Insulaner und alle von ihr infiltrierten Teile der Welt den Punkt als Dezimaltrennzeichen. Somit ist das Komma "über" und wird als Delimiter benutzt.

HiassofT hat geschrieben:Ich persönlich habe die besten Erfahrungen damit gemacht, alle Felder immer unter Anführungszeichen zu setzen (laut RFC nicht zwingend vorgeschrieben) und als Trennzeichen eben das Komma zu verwenden....

Das führt bei vielen kleinen Feldern aber zu einer extremen Ballast, die man sich sparen kann. Und je nach "Inelligenz" des Zielsystems hat man damit dann seine Problemchen, wenn Zahlen und Werte als Text eingelesen werden.

HiassofT hat geschrieben:wie sind die Felder der Datensätze zu interpretieren (Text, Integer, Float, ...). Letzteres wird aber im CSV Format garnicht behandelt (genauso wie die Zeichencodierung) - dafür muss man XML oder ähnliches heranziehen.

Das stimmt natürlich, deswegen sollte csv auch der letzte Ausweg sein. Von DB zu DB gibt es meist bessere Wege. Access bietet für csv aber die Spezifikationen bzw die schema.ini an, die genau das Problem -zugegeben recht umständlich- lösen solllen.

eda70 hat geschrieben:Nun das wundert mich nicht. Benutzen doch die Insulaner und alle von ihr infiltrierten Teile der Welt den Punkt als Dezimaltrennzeichen. Somit ist das Komma "über" und wird als Delimiter benutzt.

Das Problem hast Du mit jedem Delimiter. Man sollte auch nicht vergessen, daß die Ursprünge des CSV "Formats" sehr weit zurückreichen.

HiassofT hat geschrieben:Ich persönlich habe die besten Erfahrungen damit gemacht, alle Felder immer unter Anführungszeichen zu setzen (laut RFC nicht zwingend vorgeschrieben) und als Trennzeichen eben das Komma zu verwenden....

Das führt bei vielen kleinen Feldern aber zu einer extremen Ballast, die man sich sparen kann. Und je nach "Inelligenz" des Zielsystems hat man damit dann seine Problemchen, wenn Zahlen und Werte als Text eingelesen werden.

Eventueller "Ballast" ist sekundär. Wichtig ist die Interoperabilität mit möglichst vielen Zielsystemen. Meiner Erfahrung nach war die automatische Erkennungsrate dabei am höchsten.

Ich beharre auch nicht darauf, alle Felder unter Anführungszeichen zu setzen, aber ich empfehle eindringlich für alle neuen Applikationen das in RFC4180 beschriebene Format zu verwenden.

Natürlich darf jeder für sich entscheiden ob er es anders machen will und sich damit absichtlich selbst in den Fuss schiesst, ob das sinnvoll ist sei aber dahingestellt.

so long,

Hias

Hi Holger,

noch mal ne andere Sache: hast Du mal überschlagen, wieviele Einträge Du mit der aktuellen Datenstruktur auf einer ED/DD/..D Disk so speichern kannst? Die PD-Liste wird ja recht umfangreich werden, wenn die Programme einzeln erfasst werden. Außerdem gibt es dann ja noch die 64 Dateien-Beschränkung bei einigen DOSen, was für die Textfiles relevant werden könnte.

Gruß,

Michael

mp-one hat geschrieben:Hi Holger,

noch mal ne andere Sache: hast Du mal überschlagen, wieviele Einträge Du mit der aktuellen Datenstruktur auf einer ED/DD/..D Disk so speichern kannst? Die PD-Liste wird ja recht umfangreich werden, wenn die Programme einzeln erfasst werden. Außerdem gibt es dann ja noch die 64 Dateien-Beschränkung bei einigen DOSen, was für die Textfiles relevant werden könnte.

Gruß,

Michael

Es wird nicht alles auf eine Disk und schon garnicht in eine Datei gehen. Folglich wird es Aufsplittungen geben. Diese sind dann nach Übergenres.
Nach momentanem Stand gehen in einen Sektor 3 Datensätze. Da geht also einiges, abhängig von der Länge der Beschreibungstexte. Die sind in der Regel so 1 Sektor lang, bis zu 3 Sektoren sind es bei einer Ansichtsseite im Programm.

DOS würde ich XDOS favorisieren. Die Testversion ist ja noch auf einer Disk mit DOS2.5. bleibt aber nicht so und hängt damit zusammen, dass ich schon vor Veröffentlichung von XDOS daran gebastelt habe.
Dennoch wäre mal interessant, welche DOS wieviel Dateien verwalten können. Man kommt ja dann doch auf 2-300 Dateien pro Disk, oder gar mehr.

Gruss, Holger

Rockford hat geschrieben:

mp-one hat geschrieben:Hi Holger,

noch mal ne andere Sache: hast Du mal überschlagen, wieviele Einträge Du mit der aktuellen Datenstruktur auf einer ED/DD/..D Disk so speichern kannst? Die PD-Liste wird ja recht umfangreich werden, wenn die Programme einzeln erfasst werden. Außerdem gibt es dann ja noch die 64 Dateien-Beschränkung bei einigen DOSen, was für die Textfiles relevant werden könnte.

Gruß,

Michael

Es wird nicht alles auf eine Disk und schon garnicht in eine Datei gehen. Folglich wird es Aufsplittungen geben. Diese sind dann nach Übergenres.
Nach momentanem Stand gehen in einen Sektor 3 Datensätze. Da geht also einiges, abhängig von der Länge der Beschreibungstexte. Die sind in der Regel so 1 Sektor lang, bis zu 3 Sektoren sind es bei einer Ansichtsseite im Programm.

DOS würde ich XDOS favorisieren. Die Testversion ist ja noch auf einer Disk mit DOS2.5. bleibt aber nicht so und hängt damit zusammen, dass ich schon vor Veröffentlichung von XDOS daran gebastelt habe.
Dennoch wäre mal interessant, welche DOS wieviel Dateien verwalten können. Man kommt ja dann doch auf 2-300 Dateien pro Disk, oder gar mehr.

Gruss, Holger

Moijn zusammen!

Aus Gründen der Kompatibiltät und Nutzbarkeit dürfte DOS 2.5 in ED (MD) der kleinste gemeinsame Nenner sein. Oder anders ausgedrückt: User mit 64K-XL/XE und einer 1050 ohne Erweiterung.

Die Kategorien (derzeit 10) aus ClubMag88 liefern die Abgrenzungen zwischen den einzelnen Softwaretypen/Programmen (=Genres). Inkl. Untergruppen bei den Genres sollten 100 (00-99) Schlüssel reichen, um alle Software ausreichend indizieren zu können.

Moin,

Dennoch wäre mal interessant, welche DOS wieviel Dateien verwalten können. Man kommt ja dann doch auf 2-300 Dateien pro Disk, oder gar mehr.

bei DOS 2.5 sind es jedenfalls 64. Bei MyDOS kann man, glaube ich, 64 pro Unterverzeichnis anlegen. Bei XDOS dürften es ebenfalls 64 sein, da bin ich mir aber nicht ganz sicher.

Bei MyDOS kann man z.B. über XIO 41 CHANGE DIR und XIO 42 CREATE DIR auch von Turbo BASIC aus mit Unterverzeichnissen arbeiten. Sowas ist extrem hilfreich, auch im Hinblick auf die (optionale) Nutzung von großen Disk-Images...

Gruß,

Michael

Hi nochmal!

Aus Gründen der Kompatibiltät und Nutzbarkeit dürfte DOS 2.5 in ED (MD) der kleinste gemeinsame Nenner sein. Oder anders ausgedrückt: User mit 64K-XL/XE und einer 1050 ohne Erweiterung.

Das denke ich auch. Ich vermute mal, ein Großteil der User hat genau diese Konfiguration. Trotzdem hätte es was, wenn man optional alles zusammen in ein 16MB-ATR packen könnte und es dann z.B. per SIO2USB am Stück durchsuchen könnte.

Es wird nicht alles auf eine Disk und schon garnicht in eine Datei gehen. Folglich wird es Aufsplittungen geben. Diese sind
dann nach Übergenres.

Bei 3 Datensätzen pro Sektor kommt man dann, je nachdem ob TBXL (145 Sect/128Byte) und der PD-Reader (~150-200 Sect.) mit auf der Disk sind, auf 700 bis 900 freie Sektoren. Das wären dann ja schon >= 2100 Einträge.

Es wäre vielleicht zu überlegen, die Kopfdaten möglichst so lange es platzmäßig geht, auf einer Disk zusammenzufassen. Die Erläuterungs-Texte könnten dann auf weiteren Disks abgelegt werden. Vielleicht kann man das so flexibel gestalten, dass die Text-Datei zu einem Eintrag zuerst auf D1: und dann nachfolgend auf D2..Dn gesucht wird, soweit vorhanden. So hätte man die Wahl, ob man die Texte mit auf der ersten Disk hat oder lieber auf einer getrennten 2ten usw. Disk.

Gruß,

Michael

GoodByteXL hat geschrieben:Aus Gründen der Kompatibiltät und Nutzbarkeit dürfte DOS 2.5 in ED (MD) der kleinste gemeinsame Nenner sein. Oder anders ausgedrückt: User mit 64K-XL/XE und einer 1050 ohne Erweiterung.

Die Kategorien (derzeit 10) aus ClubMag88 liefern die Abgrenzungen zwischen den einzelnen Softwaretypen/Programmen (=Genres). Inkl. Untergruppen bei den Genres sollten 100 (00-99) Schlüssel reichen, um alle Software ausreichend indizieren zu können.

Da ich selbst zum programmieren einen 800XL mit einer 1050 ohne Erweiterung nutze, kann ich diesen Mindeststandard auch gleich prüfen. Deswegen lege ich auch Wert auf die Struktur, mit der ja die Verarbeitungsgeschwindigkeit einher geht.

Kategorieschlüssel: Habe ich schon definiert. Muss ich Dir noch schicken, findest du aber auch am Ende des Programmes in den DATA Zeilen.

@Walter: P.S: Hast Du meine Mail erhalten?

Gruss, Holger