Jack the Grabber

Wer hat Lust sich beliebt zu machen und ein kleines Tool zu programmieren?

Anforderung:
Eine "kleine" .exe mit oder ohne GUI.
Sie soll einzelne Tabellen der intern.mdb in CSV-Dateien exportieren und importieren können.
Die fraglichen Tabellen sind:
Aufnahme, Einstellungen und Pids

Nicht nötig ist es für die Tabellen:
Offline, PMG und Senderliste, da diese Tabellen keine userspezifischen Daten enthalten.

csv-Format: Semikolon oder Tab und wenn möglich ohne Fussel (").
Für die Tabelle Einstellungen wäre ein zusätzliches Feature ein Export in ein gut lesbares "Support"-Format:
Feldname: Feldwert
Feldname: Feldwert
Feldname: Feldwert
...

Beim Import muss ein Vergleich der Spaltennamen gemacht werden, da sich bei einer neuen Jackversion die Anordnung der Spalten ändern kann und weil neue Spalten hinzukommen können.

Die Tabellen sollten einzeln ex-/importierbar sein.
Eine zusätzliche Option für alle Daten auf einmal wäre auch nett.

Das soll natürlich auch ohne installiertes Access funktionieren.

OS-Support:
Win98, Me, NT 4.0, 2000, XP (Pro), 2003
Falls Servicepacks oder andere kostenfreie Updates notwending sind, wäre das okay. Zur Not reicht auch die Unterstützung von NT 5.x.

Sprache:
C# wäre optimal, dann bestünde eventuell die Möglichkeit einer Integration in JtG. Jede andere Sprache ist aber auch gern gesehen.

Zweck des Tools:
1. Beim Update von Jack auf eine neue Version, Timerlisten und Einstellungen übertragen zu können.
2. Für Supportzwecke die Einstellungen posten zu können, deswegen das "lesbare" Support-Format.

Nachwort:
Da Levi JtG alleine programmiert, kann man ihn dabei Unterstützen, den einen oder anderen Feature-Request mit thirdparty-Tools zu befriedigen.

Falls sich Jemand findet, der dieses Tool schreiben würde, bitte ich hier um Antwort, damit nicht mehrere sich die Arbeit machen und nur die von Einem genutzt wird. Es ist ja kein Preisausschreiben, wer das schönste Tool schreibt.

Vielen Dank im voraus, auch an die, die würden, aber nicht können.

Gruß Frank

Pedant hat geschrieben:Wer hat Lust sich beliebt zu machen und ein kleines Tool zu programmieren?

Anforderung:
Eine "kleine" .exe mit oder ohne GUI.
[...]
OS-Support:
Win98, Me, NT 4.0, 2000, XP (Pro), 2003

Und damit ist das schon gestorben.

Da Levi JtG alleine programmiert

Korrektur: programmieren will! Ich hatte bereits einmal angefragt, wie es mit einer Portierung von JtG aussieht und meine Hilfe angeboten. Je eher man das angegangen wäre, desto weniger Arbeit hätte man gehabt. Interesse: mau. Schade, dass stattdessen weiter munter mit solch unglaublichen Krücken wie Access-Datenbanken (!) gearbeitet wird. So muss man (...) nun wieder das Rad neu erfinden, wenn man eben nicht Windows einsetzt. Sinnvoll ist das nicht.

Vielen Dank im voraus, auch an die, die würden, aber nicht können.

... aber nicht dürfen.

Rage

Anforderung:
Eine "kleine" .exe mit oder ohne GUI.
Sie soll einzelne Tabellen der intern.mdb in CSV-Dateien exportieren und importieren können.
Die fraglichen Tabellen sind:
Aufnahme, Einstellungen und Pids

Frage:
Warum sollen es denn eine .exe und CVS-Dateien werden ?

Mein Vorschlag wäre ADO, MSXML (Speichern der Inhalte als XML-Datei) und Script-Code.

Beim Import muss ein Vergleich der Spaltennamen gemacht werden, da sich bei einer neuen Jackversion die Anordnung der Spalten ändern kann und weil neue Spalten hinzukommen können.

Solange sich die existierenden Spaltennamen nicht ändern, macht das ADO bei entsprechender Anweisung automatisch richtig.

Die Tabellen sollten einzeln ex-/importierbar sein.
Eine zusätzliche Option für alle Daten auf einmal wäre auch nett.

Für jede Tabelle das Script (am besten getrennte Scripts für Ex-/Import) einmal aufrufen, notfalls per Batch-Datei für alle zusammen.

Das soll natürlich auch ohne installiertes Access funktionieren.

OS-Support:
Win98, Me, NT 4.0, 2000, XP (Pro), 2003
Falls Servicepacks oder andere kostenfreie Updates notwending sind, wäre das okay. Zur Not reicht auch die Unterstützung von NT 5.x.

Wie es mit der Unterstützung des Scripting für Win98 aussieht, weiß ich nicht so genau ... ist halt schon etwas aus der Mode gekommen; alle anderen sollten kein Problem darstellen und die benötigten Komponenten stehen zum freien Download bereit bzw. sind auf jedem halbwegs aktuellen Windows-System ohnehin bereits installiert.

Sprache:
C# wäre optimal, dann bestünde eventuell die Möglichkeit einer Integration in JtG. Jede andere Sprache ist aber auch gern gesehen.

Script-Code ist sicherlich nicht "hohe Schule" ; aber da die Aufgabe nun wirklich nicht zeitkritisch ist, wäre die einfache Wartung (ein Text-Editor reicht) ein gutes Argument ...

Außerdem ließe es sich auch so gestalten (GetSchema), daß sich das Script automatisch an die jeweils aktuelle Tabellenstruktur anpaßt.

MfG

.PeH

PS: Selbstverständlich wirke ich gerne mit ...

Hallo Peterpawn,

wenn Du bereit wärst, das mit Ado umzusetzen, was auch immer das ist, dann habe ich in allen von Dir genannten Punkten kein Problem damit und freue mich über Deine Initative und auf Dein Ergebnis.

Gruß Frank

und freue mich über Deine Initative und auf Dein Ergebnis.

... wenn sich niemand weiter meldet und eine andere Idee hat, mache ich mich am Wochenende an die Arbeit.

Gute N8

.PeH

Tja, kann nix mehr; meine Zeit ist seit Atari 800XL vorbei.....

@RageForOrder: Danke für Deinen unglaublich konstruktiven Beitrag.
Es ist ein Unterschied, ob man eine komplette Portierung vornehmen will oder nur Funktionen outsourcen möchte.
Dann sag mir mal, da Du Access für eine Krücke hältst, wie eine einfachere Verwaltung der Daten unter Windows erfolgen soll. Ich rede da nicht von den Timern und den Optionen, sondern von den Seriendaten und/oder dem PMG.
Der Klickfinder arbeitet übrigens auch mit einer Access Datenbank und da durch den Klickfinder die Idee zu JtG überhaupt erst entstanden ist und ich eh auf diese Accessdatenbank zugreifen muss, warum soll ich dann das oledb nicht auch für "meine" Optionen und Serien nehmen ?

LEvi

Levithan hat geschrieben:@RageForOrder: Danke für Deinen unglaublich konstruktiven Beitrag.

Bitte schön. Wie ich schon sagte: Das Angebot zu einem konstruktiven Beitrag (hinsichtlich Portierung bzw. Refactoring von JtG, so dass es portabel wird) wurde bisher nicht angenommen. Ich würde mich freuen, wenn sich das ändern würde!

Es ist ein Unterschied, ob man eine komplette Portierung vornehmen will oder nur Funktionen outsourcen möchte.

Agreed. Ich habe das nur zum Anlass genommen, meiner Enttäuschung über das im ersten Absatz genannt zum Ausdruck zu bringen.

Dann sag mir mal, da Du Access für eine Krücke hältst, wie eine einfachere Verwaltung der Daten unter Windows erfolgen soll. Ich rede da nicht von den Timern und den Optionen, sondern von den Seriendaten und/oder dem PMG.

Nun, kommt darauf an, was man möchte. (Und mein Anliegen ist ja gerade, dass man sich nicht auf Windows und bestimmte Windows-DB festlegt.) Wenn man unbedingt eine "echte" Datenbank dafür nehmen möchte, dann bieten sich IMHO solche an, die es auch für andere Plattformen gibt (MySQL und Konsorten). Ansonsten liegt als Datenformat XML nahe.

Der Klickfinder arbeitet übrigens auch mit einer Access Datenbank und da durch den Klickfinder die Idee zu JtG überhaupt erst entstanden ist und ich eh auf diese Accessdatenbank zugreifen muss, warum soll ich dann das oledb nicht auch für "meine" Optionen und Serien nehmen ?

Weil Access proprietär ist.

Tut mir leid, wenn meine Mail destruktiv herumgekommen ist; das war nicht meine Intention. Ich bin nach wie vor sehr an konstruktiver Mitarbeit interessiert! (... und Euch für Eure Arbeit -- nicht zuletzt am JtG-Image -- sehr dankbar!) Ich würde mich aber über eine etwas weniger Windows-zentrierte Ausrichtung freuen. udrec beweist doch, dass sich C#/.NET und "alternative Betriebssysteme" nicht ausschließen müssen. Ich bin da zu allen Schandtaten bereit!

Rage

Nun, kommt darauf an, was man möchte. (Und mein Anliegen ist ja gerade, dass man sich nicht auf Windows und bestimmte Windows-DB festlegt.) Wenn man unbedingt eine "echte" Datenbank dafür nehmen möchte, dann bieten sich IMHO solche an, die es auch für andere Plattformen gibt (MySQL und Konsorten). Ansonsten liegt als Datenformat XML nahe.

Ich soll also von jedem User verlangen, nebenbei noch eine mysql Datenbank zu installieren und zu konfigurieren. Aber halt, mysql kann ja keine stored procedures, also wäre postgreeSQL wohl die richtige Wahl um bei späterer Verwendung dieser auch gerüstet zu sein. Leider gibt es keine Umsetzung für Windows, aber der User kann ja nebenbei noch cygwin laufen haben, um dies zu nutzen. Stimmt, ist besser als das

proprietär

Access.
XML ist auch eine Alternative und bei 5000 Datensätzen sicher auch super schnell

Tut mir leid, wenn meine Mail destruktiv herumgekommen

dito für diese ironische Antwort

udrec beweist doch, dass sich C#/.NET und "alternative Betriebssysteme" nicht ausschließen müssen

Sehe ich ganz genauso (ohne ironie ), allerdings ist die Form Klasse imho noch garnicht oder nur in Ansätzen in mono enthalten. Da lass ich mich aber gerne eines besseren belehren.

Ich bin da zu allen Schandtaten bereit!

Ich grundsätzlich auch, aber der Tag hat auch bei mir nur 24 Stunden, bei welchen mind. 10 für den Job draufgehen
Wir können uns diesbezüglich aber gerne mal zusammenhocken.

Levi

XML ist auch eine Alternative und bei 5000 Datensätzen sicher auch super schnell

Genau mit der Thematik hab ich mich in den letzen Tagen auseinandergesetzt und bin dabei an XML gescheitert, weil wie Levi schon beschrieben hat, XML einfach zu langsam ist. Man hat einfach keine Lust bei 10.000 Datensätzen zwei Minuten warten zu müssen, wenn die selbe Arbeit (füllen einer ListView mit gerade mal 4 Spalten) mit einer AccessDB nur wenige Sekunden dauert.

Wenn du mir andere Datenbank-Systeme anbieten kannst, die keine zusätzlichen Kosten verursachen und so einfach gehandhabt werden können wie Access, wäre ich dir sehr dankbar. Ich selbst hab nämlich nichts gefunden!

Cu leth

Levithan hat geschrieben: Ich soll also von jedem User verlangen, nebenbei noch eine mysql Datenbank zu installieren und zu konfigurieren. Aber halt, mysql kann ja keine stored procedures, also wäre postgreSQL wohl die richtige Wahl um bei späterer Verwendung dieser auch gerüstet zu sein. Leider gibt es keine Umsetzung für Windows, aber der User kann ja nebenbei noch cygwin laufen haben, um dies zu nutzen.

Ganz billiger Versuch, Access als einzig sinnvolle Alternative darzustellen. Wie ich schon sagte: Es kommt darauf an, was man will und braucht. Was genau braucht Jack denn? Und ja, man kann auch Datenbank (mit) installieren, wenn man das wirklich benötigt. In der Palette von Plain Text-Dateien über dateibasierte Datenbanken bis hin zu MySQL ist auch was für Jack dabei, wette ich.

Access ist sicherlich bequem, keine Frage, aber es ist ganz gewiss nicht die einzig mögliche Lösung. Und es ist genauso wenig die einzig praktikable Lösung.

Ich bin mir in jedem Fall sicher, dass sich für den gewünschten Anwendungszweck eine andere Alternative finden lässt, welche einerseits die nötige Performance bietet und andererseits auch jenseits von Windows realisierbar ist. (Dazu müsste ich erst einmal wissen, wozu wann, warum, in welchem Umfang welche Daten daraus benötigt werden.)

XML ist auch eine Alternative und bei 5000 Datensätzen sicher auch super schnell

Wenn die Performance des XML-Parsers Deiner Wahl zu schlecht ist, dann nimmst Du halt eine Datenbank. Käme auf einen Versuch und die Struktur / Menge der Daten an. Woher kommen überhaupt die 5000 Datensätze? Serieninfos?

udrec beweist doch, dass sich C#/.NET und "alternative Betriebssysteme" nicht ausschließen müssen

Sehe ich ganz genauso (ohne ironie ), allerdings ist die Form Klasse imho noch garnicht oder nur in Ansätzen in mono enthalten. Da lass ich mich aber gerne eines besseren belehren.

Ich habe bisher mit C#/Mono nichts am Hut (das wäre aber kein großes Problem), insofern kann ich dazu nichts sagen. Ich habe ja nicht gesagt, dass es einfach werden würde, Jack portabel zu gestalten. Es ist halt wie bei der Verwendung von Access die Frage, ob man sich auf eine Plattform festlegen möchte, um es vielleicht (!) etwas bequemer zu haben, oder ob man hier und dort etwas mehr investiert, um dann aber betriebssystemunabhängiger zu sein.

Ich bin da zu allen Schandtaten bereit!

Ich grundsätzlich auch, aber der Tag hat auch bei mir nur 24 Stunden, bei welchen mind. 10 für den Job draufgehen

Schon klar, geht mir nicht anders.

Wir können uns diesbezüglich aber gerne mal zusammenhocken.

Das müsste dann sicherlich virtuell erfolgen. IRC?

Hätten vielleicht noch mehr Leute Interesse an einer Portierung? Arbeitet tonsel nicht auch (zumindest teilweise) unter Linux? Er wäre doch hinsichtlich C# / Mono anscheinend auch schon "vorbelastet". tonsel?

Rage

Ganz billiger Versuch, Access als einzig sinnvolle Alternative darzustellen.

Nicht billig, aber ich argumentiere.
Okay, dann schreibe mal rasch ein Parser für das PMG und baue eine Guide mit Suchfunktion aus einem Plain Text oder per XML. Wenn das genauso performent wie access ist, gebe ich mich geschlagen
Was mir an Deinem Beitrag noch immer fehlt ist eine Begründung, warum ich KEIN access nehmen soll, wenn ich für den Klickfinder eh oledb machen muss.

Wenn die Performance des XML-Parsers Deiner Wahl zu schlecht ist, dann nimmst Du halt eine Datenbank

vielleicht access ?

Woher kommen überhaupt die 5000 Datensätze? Serieninfos?

Serien sind momentan 3800 Einträge. Das PMG muss ich leider schätzen, da ich kein aktuelles File auf Arbeit habe, sollten aber locker > 5000 Einträge sein.

Das müsste dann sicherlich virtuell erfolgen. IRC?

Davon ging ich aus

Es ist halt wie bei der Verwendung von Access die Frage, ob man sich auf eine Plattform festlegen möchte, um es vielleicht (!) etwas bequemer zu haben, oder ob man hier und dort etwas mehr investiert, um dann aber betriebssystemunabhängiger zu sein.

Da stellt sich aber die Frage, ob eine Portierung überhaupt Sinn machen würde. Wer würde dies unter Linux auch tatsächlich nutzten ?
Was an Linux wirklich abgeht (meine persönliche Einstellung) ist die Konsole, aber da kann ich ja bequem udrec oder ggrab nehmen.
Versteh mich nicht falsch, ich finde die Idee super und im Falle eines Erfolges könnte ich auch endlich meinen Server wieder mit Linux betreiben, aber ob es der Aufwand wert ist, wage ich zu bezweifeln. Das kommt aber auf einen Versuch an.
Ich werde mir heute Abend oder morgen nochmal das mono reinziehen.

Levi

Also ich bin für Levi. Ausser wenn RageForOrder schnell ein Proggi schreibt, das mir noch besser als Jack gefällt. Dann bin ich natürlich für ihn.
Mal im Ernst und ohne Diskreminierung anderer OS - ich bin froh, dass es so ein tolles Proggi wie Jack überhaupt gibt und nehme halt das OS, unter dem es läuft zum Streamen (naja, zufälligerweise nehme ich auch sonst Win - aber wenn Jack nur für Linux wäre würde ich eben meinen Streaming-Rechner mit Linux ausrüsten).
cu, Relaff

OS hin OS her.
Es geht doch nicht darum welches Betriebssystem man nimmt und welches nicht.
Es geht darum was effektiver und effizienter ist. Und was leichter mit wenig Zeit zu realisieren ist.
Ich sehe da klare Vorteile bei Windows. Es ist einfach komfortabler, einfacher für "Windows" zu entwickeln als für andere OS's.
Ich möchte nicht wissen um wieviel Prozent der Aufwand steigen würde, wenn man den Jack in Java entwickeln würde.
Außerdem sehe ich auch bei Multimedia-Anwendungen klar Windows im Vorteil, obwohl ich auch jahrelanger Linux-User bin.

Ciao
Lukas

Levithan hat geschrieben: Okay, dann schreibe mal rasch ein Parser für das PMG und baue eine Guide mit Suchfunktion aus einem Plain Text oder per XML. Wenn das genauso performent wie access ist, gebe ich mich geschlagen

Hupps? Verstehe ich jetzt etwas nicht? Der PMG kommt doch ohnehin im Textformat daher (und als PDF), aber eben nicht als fertige Access-DB, oder habe ich was verpasst? Den musst Du doch ohnehin parsen, njet? Und ja, ich behaupte, dass sowas mit Perl oder Python oder <insert favorite scripting language here> sehr schnell geht.

Levithan hat geschrieben:Was mir an Deinem Beitrag noch immer fehlt ist eine Begründung, warum ich KEIN access nehmen soll, wenn ich für den Klickfinder eh oledb machen muss.

Tja, wenn der Klickfinder das nutzt, dann hat mal wohl Pech. Ob ich deswegen Access für die eigenen Daten nehmen würde, hmm, eher nicht, aber das ist jetzt meine persönliche Abneigung.

Levithan hat geschrieben:Da stellt sich aber die Frage, ob eine Portierung überhaupt Sinn machen würde. Wer würde dies unter Linux auch tatsächlich nutzten ?

Ich! (BTW: Du plenkst ... )

Levithan hat geschrieben:Was an Linux wirklich abgeht (meine persönliche Einstellung) ist die Konsole, aber da kann ich ja bequem udrec oder ggrab nehmen.

Äh, ich wieder nix verstehen. "Was an Linux wirklich abgeht [...] ist die Konsole?"

Levithan hat geschrieben:Versteh mich nicht falsch, ich finde die Idee super und im Falle eines Erfolges könnte ich auch endlich meinen Server wieder mit Linux betreiben, aber ob es der Aufwand wert ist, wage ich zu bezweifeln.

Das kapiere ich jetzt wieder nicht (call me stupid ). Ich gebe zu meiner Schande zu, dass ich Jack jetzt länger nicht mehr benutzt habe (weil ich Windows nur im "Notfall" boote), aber ist es nicht so, dass man Jack als Frontend für einen auf einem anderen Rechner laufenden Streaming Server (udrec!) verwenden kann? Warum sollte dieses udrec nicht unter Linux laufen (wie hier bei mir)?

Levithan hat geschrieben: Ich werde mir heute Abend oder morgen nochmal das mono reinziehen.

Ich hatte vorhin kurz mal geschaut, und Forms scheint mono tatsächlich noch nicht zu können. Wäre genial, wenn Du als C#-Kenner mal genauer gucken könntest, was mono fehlt bzw. wie viel Aufwand es wäre, Jack auf mono zu trimmen. Dann könnten wir uns gern im Chat (IRC, ICQ, ...) treffen um zu besprechen, ob das mit vertretbarem Aufwand machbar wäre.

Kurz noch ein paar Anmerkungen zu weiteren Kommentaren aus dem Forum:

relaff hat geschrieben: Mal im Ernst und ohne Diskreminierung anderer OS - ich bin froh, dass es so ein tolles Proggi wie Jack überhaupt gibt und nehme halt das OS, unter dem es läuft zum Streamen (naja, zufälligerweise nehme ich auch sonst Win - aber wenn Jack nur für Linux wäre würde ich eben meinen Streaming-Rechner mit Linux ausrüsten).

Tja, der "Streaming-Rechner" läuft ja unter Linux, nur leider fehlt das geeignete Frontend (läuffähig unter Linux), um udrec gescheit zu füttern. Immer per Kommandozeile aufrufen ist irgendwie nicht so schön.

aIKON hat geschrieben: OS hin OS her. Es geht doch nicht darum welches Betriebssystem man nimmt und welches nicht. Es geht darum was effektiver und effizienter ist. Und was leichter mit wenig Zeit zu realisieren ist. Ich sehe da klare Vorteile bei Windows. Es ist einfach komfortabler, einfacher für "Windows" zu entwickeln als für andere OS's.

Das kommt immer ganz auf die eigenen Kentnisse an. Diese Aussage kann ich so jedenfalls überhaupt nicht unterschreiben. Und wenn es den Nutzen hat, dass eine Anwendung nicht nur unter Windows läuft, dann bin ich bereit, auch etwas darin zu investieren.

aIKON hat geschrieben: Ich möchte nicht wissen um wieviel Prozent der Aufwand steigen würde, wenn man den Jack in Java entwickeln würde.

Oha, da spricht der Experte. Im Grunde gilt oben Gesagtes. Für mich wäre der Aufwand, Jack in Java zu implementieren, jedenfalls deutlich geringer, als Jack in C# zu programmieren.

aIKON hat geschrieben:Außerdem sehe ich auch bei Multimedia-Anwendungen klar Windows im Vorteil, obwohl ich auch jahrelanger Linux-User bin.

Das mag noch so sein. Aber ich sehe keinen Grund, warum das so bleiben sollte.

Rage