Daten-Odyssee: ACT!6
Seit ich den Job in Karlsruhe habe, werde ich mit Geld gezwungen für Windows zu entwicken. Ich weiß, einige Leute werden jetzt feixen ;-)
Die Firma setzt ACT! ein, eine CRM-Software mit der sich relativ einfach Oberflächen zusammenklicken lassen. Das wars aber auch schon. Die eingesetzte Version 6 benutzt DBase-Dateien, um die Daten zu speichern. Mehrbenutzerzugriff muss über die Windows Dateifreigabe gelöst werden. Das Programm hat bereits bei 5000-6000 Kunden-Adressen und vier Mitarbeitern gleichzeitig arge Probleme mit der Performance. Und es speichert die Daten nicht in vernünftig, sondern über 5 fünf bis sechs Datenbank-Dateien verteilt. Es gibt zwar eine Modell-Zeichnung, aber die kann man in der Pfeife rauchen.
Da ACT! einige Elementare Dinge nicht kann, ist es meine Aufgabe, sie nachzubilden. Da ausserdem auch eine Anbindung dieser Daten an das Indernett geplant ist, habe ich mich gar nicht erst damit agegeben, eine eventuelle Plugin-Schnittstelle zu erforschen - die AFAIK sowieso nur kostenpflichtig zur Verfügung steht. Statt dessen habe ich mir einen Weg gesucht, die Daten irgendwie aus dem Programm herauszubekommen. Zuerst wollten wir auf ACT!7 umsteigen, da dort der Microsoft SQL-Server benutzt wird. Das wäre optimal gewesen, da ich da wahrscheinlich recht einfach an die Daten gekommen wäre. Leider ist der allerdings mit einem Passwort geschützt, und die Firma SAGE tut alles um zu verhindern, dass man an das Passwort kommt. Mich würde mal interessieren, ob das so rechtens ist. Hm. Deshalb und weil ACT!7 den Arbeitgeber etwa 5000€ bis 6000€ gekostet hätte, haben wir uns dann dagegen entschieden und weiter nach einem Weg gesucht, die Daten zu bekommen.
Der nächste Gedanke war: die nutzen DBase. Für DBase gibt es mehr als genug Bibliotheken. Ich habe etwa einen Tag damit verbracht, mir die Sachen anzuschauen und versucht herauszufinden, wo ich welche Datenzusammensammeln muss, aber es dann wieder verworfen: es war nahezu aussichtslos, da die Zeit, die das Reverse-Engineering in Anspruch nehmen würde ist für den Arbeitgeber untragbar.
Allerdings gibt es eine OLE-Schnittstelle zu der Datenbank. Bisher sieht es so aus, als würde ich darüber relativ einfach an die Daten kommen. Der OLE-Zugriff über VB.NET oder C#.NET ist ja relativ einfach gestrickt. Und abgesehen vin einigen Unstimmigkeiten scheint es bisher auch recht gut zu funktionieren. Aber ich bleibe misstrauisch. Wir reden hier schliesslich von einer Microsoft-Erfindung! ;-)