Tach auch!
Für die, die die Hintergründe kennen, ganz kurz: Heute habe ich den Datenbestand der aktuellen ft-Datenbank aka ft:db 3.0 erfolgreich importieren und somit in einem von mir weiterverarbeitbaren Zustand bringen können. Das ist hier bei mir im Büro in einer Kopie der SQL Server-Datenbank von SF Parts.
Für Leute, die all die Hintergründe und Historie nicht kennen, hier, soweit ich sie weiß, die Geschichte der ft:db:
1. Es gab mal eine ftdb 1.0. Die lief im Web. U.a. Karl Tillmetz lieferte wohl damals schon Daten, und soweit ich weiß, wurde die zugehörige Website von Defiant gebaut (korrigiere mich bitte, wenn ich falsch liege, Defiant).
2. Irgendwann kam schnaggels auf mich zu und fragte, ob ich die DB-Struktur für eine ftdb 2.0 entwerfen könnte, mit Sprachen, Farbvarianten, mehreren Artikelnummern für denselben Artikel und so Sachen (beruflich mache ich so DB-Kram). Daraus ergab sich, dass ich auch den Import der Daten von Karl Tillmetz u.a. übernehmen sollte. Deshalb habe ich damals ein Windows-Programm namens SF Parts unter Verwendung meiner "Automatik" (https://www.ct-systeme.com/sf/ApplicationCreator/) gebaut. Das macht es enorm leicht, langfristig wart- und erweiterbare Datenbankanwendungen mit dem Microsoft SQL Server als Datenbanksystem (und seinen SQL Server Reporting Services für Berichte, Etiketten etc.) für Windows, Dienste, Kommandozeilenanwendungen etc. zu schreiben, und dieses Framework hatte wegen Kundenanwendungen auch schon Bilder und Dokumente in der DB gelernt. Aus SF Parts habe ich dann regelmäßig nach Änderungen die Daten zunächst als SQL-Statements für MySQL, später für PostgreSQL exportiert, die auf dem ftc-Webserver eingelesen wurden. Eine php-Seite, die im Wesentlichen von Sven gemacht wurde, hat diese Daten dann dargestellt und abrufbar gemacht. Das war also die ft:db 2.0. Ein Problem damit war aber, dass nur ich selbst die Daten (in SF Parts nämlich) pflegen und dann wieder zur ftc exportieren konnte. SF Parts nur bei mir mit Pflegen --> Export zur ftc --> Darstellung im Web.
3. Also suchten wir eine Lösung mit einer webbasierten Pflege der Datenbestände, und glücklicherweise sprang uns bummtschick zur Seite. Der hatte ein Framework für sowas in Arbeit und hat damit die aktuelle ft:db 3.0 gebaut und alle in SF Parts liegenden Daten von mir bekommen. Durch die Möglichkeit, Daten direkt übers Internet im Browser zu pflegen, konnten fleißige Helfer wie Pudy viele Daten ergänzen und die DB so aktualisieren.
4. Vor längerer Zeit schon trat leider ein technisches Problem auf, sodass man die Daten zwar noch lesen, aber nicht mehr pflegen konnte. Pudy hätte also gerne weiter Daten eingepflegt, es ging aber nicht mehr. Schlimmer: Wir konnten es nicht richten, und bummtschick hatte leider gar keine Zeit mehr für das Projekt. Damit war der aktuelle Stand der DB in tatsächlicher Gefahr. Nicht nur, dass niemand pflegen konnte, hätte das System ja auch irgendwann gar nicht mehr laufen oder auf aktuellen Versionen von Betriebssystemen etc. arbeiten können.
5. Richard gelang es nun, das Datenbankschema und die Datenbankinhalte aus der der ft:db 3.0 zugrunde liegenden Postgres-Datenbank zu exportieren und mir beides zusammen mit allen den gespeicherten Bildern und Dokumenten zur Verfügung zu stellen. So entstand der Plan, das bei mir immer noch vorliegende SF Parts zu benutzen und einen Import zu schreiben, der erkennt, was sich seit der letzten von SF Parts exportierenden Version 2.0 der ftdb und der aktuellen Version 3.0, incl. der online erfolgten Ergänzungen geändert hat. Das ist nun gelungen. Heute hat SF Parts die Daten - vorbehaltlich einer Prüfung; es könnte ja noch ein Bug drin stecken - der ft:db 3.0 importiert. Die dabei erkannten Unterschiede liefert das ausführliche Importprotokoll am Ende so:
- 1 Kategorien angelegt
- 2.479 Artikelbezeichnungen geändert
- 70 Artikelkategorien geändert
- 6 Artikelgewichte geändert
- 776 Artikelbemerkungen geändert
- 289 Artikel hinzugefügt
- 289 Artikelvarianten hinzugefügt
- 232 Artikelnummern angelegt
- 4 Artikelnummern geändert
- 58 Artikelnummern entfernt
- 242 Bilder hinzugefügt
- 9.280 Bilder entfernt
- 18 Dokumente hinzugefügt
- 9 Dokumente entfernt
- 5.631 Stücklisteneinträge hinzugefügt
- 68 Stücklisteneinträge geändert
- 145 Stücklisteneinträge entfernt
- 1 Stücklisteneinträge waren ungültig
Euch werden wie mir die 9.280 gelöschten Bilder überraschen. Das schaue ich mir natürlich noch alles ganz genau an, bevor ich das in die (ebenfalls nur bei mir liegenden) "Produktiv"-Version von SF Parts einspiele.
Selbst wenn der Import doch noch irgendwas falsch gemacht haben sollte und wir das erst drei Jahre später merken: SF Parts führt ein lückenloses Änderungsprotokoll, das hinreichend ausführlich ist, dass wir auch alte Änderungen (incl. Löschungen, auch für Bilder und Dokumente) einfach wieder rückgängig machen können. Und Backups habe ich auch jede Stunde, die letzten 14 Tage, die letzten 6 Wochen und die letzten 3 Jahre. Da wird also nichts anbrennen, selbst wenn ich einen Fehler drin hab.![:-)]( "Lächeln")
Das ist also der aktuelle Stand. Der aktuelle 3.0-Datenbestand ist auf jeden Fall mal gesichert und gerettet. Ich hier bei mir könnte ihn auch pflegen, aber eben leider nur ich und nur hier. Das ist also noch nicht das Ende der Arbeit. Wer und wie auch immer wann auch immer mal eine ft:db 4.0 mit web-fähiger Pflege baut - und bitte *langfristig* auch für Support und Dokumentation da ist - kann von mir auf jeden Fall alle Daten in welcher benötigten Form auch immer übergeben bekommen, solange ich noch schnaufe.
Bis dahin kann ich ja zumindest mal die Änderungen, die mich oder den ftc-Vereinsvorstand per Mail oder auch hier im Forum erreichten, schon mal in SF Parts einpflegen. Evtl. können wir aktueller gepflegte Daten aus Svens eigener Microsoft-Access-Datenbank oder von weiteren ft-Fans irgendwann auch importieren. Damit das allen nutzt, muss aber erstmal irgendwas her, womit man die Daten auch im Web abrufen und idealerweise eben auch pflegen kann.
Wenn sich jemand "bewerben" möchte, der eine webfähige ftdb 4.0 machen und die auch bitte viele Jahre lang supporten bzw. den Support auch wirklich an weitere übergeben kann, würden sich sicher alle ft-Fans freuen. Wir wollen nur nicht, dass eine Lösung einige Jahre läuft und dann doch wieder ohne Migrationspfad woandershin einschläft. Idealerweise sollte es also ein fähiges Team und nicht nur eine Einzelperson dafür geben.
Die ft:db ist also noch unverändert im Netz unter ftdatenbank.de, aber immerhin haben wir einigermaßen sichergestellt, dass die Daten sauber an ein Nachfolgeprojekt übergeben werden können. Die nächsten Schritte können nun prinzipiell folgen.
Wenn jemand Verbesserungen am Datenbestand melden möchte (neue Kästen, neue Teile, Stücklisten, Korrekturen in vorhandenen Daten), also immer gerne her damit. Wichtig: Dokumente wie Anleitungen stellen wir gemäß der Vereinbarung mit der fischertechnik GmbH erst dann ein, wenn die zugehörigen Kästen nirgends (auf der Welt!) mehr verkauft werden oder Lagerbestand haben. Und natürlich brauchen wir an allen Daten die Nutzungsrechte und dürfen nicht einfach so irgendwas irgendwoher kopieren.
Auf dann.
Beste Grüße,
Stefan
Für die, die die Hintergründe kennen, ganz kurz: Heute habe ich den Datenbestand der aktuellen ft-Datenbank aka ft:db 3.0 erfolgreich importieren und somit in einem von mir weiterverarbeitbaren Zustand bringen können. Das ist hier bei mir im Büro in einer Kopie der SQL Server-Datenbank von SF Parts.
Für Leute, die all die Hintergründe und Historie nicht kennen, hier, soweit ich sie weiß, die Geschichte der ft:db:
1. Es gab mal eine ftdb 1.0. Die lief im Web. U.a. Karl Tillmetz lieferte wohl damals schon Daten, und soweit ich weiß, wurde die zugehörige Website von Defiant gebaut (korrigiere mich bitte, wenn ich falsch liege, Defiant).
2. Irgendwann kam schnaggels auf mich zu und fragte, ob ich die DB-Struktur für eine ftdb 2.0 entwerfen könnte, mit Sprachen, Farbvarianten, mehreren Artikelnummern für denselben Artikel und so Sachen (beruflich mache ich so DB-Kram). Daraus ergab sich, dass ich auch den Import der Daten von Karl Tillmetz u.a. übernehmen sollte. Deshalb habe ich damals ein Windows-Programm namens SF Parts unter Verwendung meiner "Automatik" (https://www.ct-systeme.com/sf/ApplicationCreator/) gebaut. Das macht es enorm leicht, langfristig wart- und erweiterbare Datenbankanwendungen mit dem Microsoft SQL Server als Datenbanksystem (und seinen SQL Server Reporting Services für Berichte, Etiketten etc.) für Windows, Dienste, Kommandozeilenanwendungen etc. zu schreiben, und dieses Framework hatte wegen Kundenanwendungen auch schon Bilder und Dokumente in der DB gelernt. Aus SF Parts habe ich dann regelmäßig nach Änderungen die Daten zunächst als SQL-Statements für MySQL, später für PostgreSQL exportiert, die auf dem ftc-Webserver eingelesen wurden. Eine php-Seite, die im Wesentlichen von Sven gemacht wurde, hat diese Daten dann dargestellt und abrufbar gemacht. Das war also die ft:db 2.0. Ein Problem damit war aber, dass nur ich selbst die Daten (in SF Parts nämlich) pflegen und dann wieder zur ftc exportieren konnte. SF Parts nur bei mir mit Pflegen --> Export zur ftc --> Darstellung im Web.
3. Also suchten wir eine Lösung mit einer webbasierten Pflege der Datenbestände, und glücklicherweise sprang uns bummtschick zur Seite. Der hatte ein Framework für sowas in Arbeit und hat damit die aktuelle ft:db 3.0 gebaut und alle in SF Parts liegenden Daten von mir bekommen. Durch die Möglichkeit, Daten direkt übers Internet im Browser zu pflegen, konnten fleißige Helfer wie Pudy viele Daten ergänzen und die DB so aktualisieren.
4. Vor längerer Zeit schon trat leider ein technisches Problem auf, sodass man die Daten zwar noch lesen, aber nicht mehr pflegen konnte. Pudy hätte also gerne weiter Daten eingepflegt, es ging aber nicht mehr. Schlimmer: Wir konnten es nicht richten, und bummtschick hatte leider gar keine Zeit mehr für das Projekt. Damit war der aktuelle Stand der DB in tatsächlicher Gefahr. Nicht nur, dass niemand pflegen konnte, hätte das System ja auch irgendwann gar nicht mehr laufen oder auf aktuellen Versionen von Betriebssystemen etc. arbeiten können.
5. Richard gelang es nun, das Datenbankschema und die Datenbankinhalte aus der der ft:db 3.0 zugrunde liegenden Postgres-Datenbank zu exportieren und mir beides zusammen mit allen den gespeicherten Bildern und Dokumenten zur Verfügung zu stellen. So entstand der Plan, das bei mir immer noch vorliegende SF Parts zu benutzen und einen Import zu schreiben, der erkennt, was sich seit der letzten von SF Parts exportierenden Version 2.0 der ftdb und der aktuellen Version 3.0, incl. der online erfolgten Ergänzungen geändert hat. Das ist nun gelungen. Heute hat SF Parts die Daten - vorbehaltlich einer Prüfung; es könnte ja noch ein Bug drin stecken - der ft:db 3.0 importiert. Die dabei erkannten Unterschiede liefert das ausführliche Importprotokoll am Ende so:
- 1 Kategorien angelegt
- 2.479 Artikelbezeichnungen geändert
- 70 Artikelkategorien geändert
- 6 Artikelgewichte geändert
- 776 Artikelbemerkungen geändert
- 289 Artikel hinzugefügt
- 289 Artikelvarianten hinzugefügt
- 232 Artikelnummern angelegt
- 4 Artikelnummern geändert
- 58 Artikelnummern entfernt
- 242 Bilder hinzugefügt
- 9.280 Bilder entfernt
- 18 Dokumente hinzugefügt
- 9 Dokumente entfernt
- 5.631 Stücklisteneinträge hinzugefügt
- 68 Stücklisteneinträge geändert
- 145 Stücklisteneinträge entfernt
- 1 Stücklisteneinträge waren ungültig
Euch werden wie mir die 9.280 gelöschten Bilder überraschen. Das schaue ich mir natürlich noch alles ganz genau an, bevor ich das in die (ebenfalls nur bei mir liegenden) "Produktiv"-Version von SF Parts einspiele.
Selbst wenn der Import doch noch irgendwas falsch gemacht haben sollte und wir das erst drei Jahre später merken: SF Parts führt ein lückenloses Änderungsprotokoll, das hinreichend ausführlich ist, dass wir auch alte Änderungen (incl. Löschungen, auch für Bilder und Dokumente) einfach wieder rückgängig machen können. Und Backups habe ich auch jede Stunde, die letzten 14 Tage, die letzten 6 Wochen und die letzten 3 Jahre. Da wird also nichts anbrennen, selbst wenn ich einen Fehler drin hab.
Das ist also der aktuelle Stand. Der aktuelle 3.0-Datenbestand ist auf jeden Fall mal gesichert und gerettet. Ich hier bei mir könnte ihn auch pflegen, aber eben leider nur ich und nur hier. Das ist also noch nicht das Ende der Arbeit. Wer und wie auch immer wann auch immer mal eine ft:db 4.0 mit web-fähiger Pflege baut - und bitte *langfristig* auch für Support und Dokumentation da ist - kann von mir auf jeden Fall alle Daten in welcher benötigten Form auch immer übergeben bekommen, solange ich noch schnaufe.
Bis dahin kann ich ja zumindest mal die Änderungen, die mich oder den ftc-Vereinsvorstand per Mail oder auch hier im Forum erreichten, schon mal in SF Parts einpflegen. Evtl. können wir aktueller gepflegte Daten aus Svens eigener Microsoft-Access-Datenbank oder von weiteren ft-Fans irgendwann auch importieren. Damit das allen nutzt, muss aber erstmal irgendwas her, womit man die Daten auch im Web abrufen und idealerweise eben auch pflegen kann.
Wenn sich jemand "bewerben" möchte, der eine webfähige ftdb 4.0 machen und die auch bitte viele Jahre lang supporten bzw. den Support auch wirklich an weitere übergeben kann, würden sich sicher alle ft-Fans freuen. Wir wollen nur nicht, dass eine Lösung einige Jahre läuft und dann doch wieder ohne Migrationspfad woandershin einschläft. Idealerweise sollte es also ein fähiges Team und nicht nur eine Einzelperson dafür geben.
Die ft:db ist also noch unverändert im Netz unter ftdatenbank.de, aber immerhin haben wir einigermaßen sichergestellt, dass die Daten sauber an ein Nachfolgeprojekt übergeben werden können. Die nächsten Schritte können nun prinzipiell folgen.
Wenn jemand Verbesserungen am Datenbestand melden möchte (neue Kästen, neue Teile, Stücklisten, Korrekturen in vorhandenen Daten), also immer gerne her damit. Wichtig: Dokumente wie Anleitungen stellen wir gemäß der Vereinbarung mit der fischertechnik GmbH erst dann ein, wenn die zugehörigen Kästen nirgends (auf der Welt!) mehr verkauft werden oder Lagerbestand haben. Und natürlich brauchen wir an allen Daten die Nutzungsrechte und dürfen nicht einfach so irgendwas irgendwoher kopieren.
Auf dann.
Beste Grüße,
Stefan
Statistik: Verfasst von steffalk — 28 Apr 2024, 16:56