Zugriff auf MS Excel

[ThoPos]

Hallo Sherlock,

ich habe versucht mir das AddIn anzusehen.

Leider findet mein Delphi 2007 die TExcel...-Komponenten nicht. Und meine Versuche diese als Typenbibliotheken zu importieren scheiterten kläglich, da immer irgendwelche Sachen fehlen.

Gruß aus Köln
Thomas

[nahpets]

Hallo,

bei Delphi 6 und 7 liegen sie unter delphi\ocx\Servers\. Eventuell wirst Du ja dort fündig.
Ansonsten suche mal im Delphiverzeichnis nach Excel*.pas.

Eventuell findest Du im BIN-Verzeichnis auch ein(ige) dclOffice*.bpl, dann musst Du nur dieses Package installieren.

[p80286]

Hallo ThoPos,

zunächst einmal verstehe ich nicht was Du gegen ODBC hast, abgesehen von der lausigen Umsetzung in Excel (so wie ich es kenne!)
aber wie wäre es mit einem anderen Ansatz:
Dein Addinn schreibt die verarbeiteten Daten in eine Datei, die dann von Deinem Delphi-Programm weiter verarbeitet wird.
Je nachdem welches Format (CSV) Du in der Datei verwendest kommst Du ohne einen erneuten Aufruf von Excel aus.

Gruß K-H

[ThoPos]

Hallo K-H,

meine Abneigung gegen ODBC ruht weniger auf die Technik als solche, sondern mehr auf
- die Umsetzung in VBA.
- das was unserere Netzwerk-Admins immer mit der Oracle-Konfiguration treiben.
Wenn ich ODAC verwende, ist mir absolut egal, was die lieben Admins machen - die DB-Anbindung steht!

Gegen Deinen Vorschlag des Datenaustausch per Datei steht - und das hatte vergessen zu schreiben - das ich auch Daten aus Oracle abhole und in die Tabelle schreibe, damit diese Informationen auch auf den Andrucken stehen. (QS und QM lassen grüßen.)

Und von der aktuellen Umsetzung sind alle Labormitarbeiter hellauf begeistert. Denn die Zusammenarbeit des Auftragssystemes (Oracle) und der Meßgeräte (Auswertung via Excel) funktioniert super.

Wäre da nicht das Problem, daß Excel ggf. mehrfach läuft.

Gruß aus Köln
Thomas

[p80286]

Hallo ThoPos,

auf die Gefahr hin Dich vollkommen mißverstanden zu haben:
1) Daten werden durch Messungen erstellt
2) Daten werden durch Excel aufbereitet/verarbeitet
3) Daten werden in Datenbank geschrieben

Irgendwo dazwischen werden auch Daten aus einer DB abgeholt um wichtige Zusatzinformationen zu erhalten.
Jetzt einmal abgesehen vom Zeitpunkt wann Du was erledigen läßt, Du arbeitest grundsätzlich mit Excel und möchtest, daß ein Delphi-Programm eine Zusatzaufgabe erledigt, die am Ende der Verarbeitungsreihenfolge liegt.
Wenn Du über die von mir vorgeschlagene Datei gehst, dann kann Delphi seine "eigene" Excel Instanz eröffnen und es ist egal was sonst noch auf dem Rechner läuft. (vgl #5 von Chemiker)

Was allerdings nur dann sinnvoll ist, wenn die "Delphi-Verarbeitung" wirklich am Ende ist.

Gruß K-H

P.S.
Die normalen Mitarbeiter müssen ja nicht mitbekommen wer da wo arbeitet.

[ThoPos]

Hallo K-H,

so vollkommen ist das Mißverständnis nicht.

Ich sortiere mal die Schritte:

A: Das Meßgerät: Messen einer Probenserie.
1. Das Meßgerät mißt kontinuierlich die Proben verschiedener Probenserien.
2. Am Ende jeder Messung schreibt die Steuersoftware des Meßgerät die Daten nach Excel. Bei diesem Schreibvorgang verwendet der Hersteller folgende Logik: Läuft eine Excel-Instanz ohne geöffnete Mappe, so wird die diese verwendet, ansonsten eine neue Instanz von Excel geöffnet. Excel-Instanzen mit geöffneten Mappen werden ignoriert. In der leeren oder neuen Excel-Instanz wird nun die Arbeitsmappe geöffnet - je Probenserie gibt es eine Mappe, bei der ersten Probe der Serie wird eine neue Mappe auf Basis einer Vorlage erstellt. In diesen Mappen werden für jede Probe der Serie eine Datenzeile geschrieben.
3. Die Mappe wird nach der Datenübertragung gespeichert und geschlossen.
4. Die Excel bleibt ohne geladene Mappe geöffnet.

B: Der Anwender in Excel: Nach dem alle Proben einer Serie gemessen wurden.
1. Öffnen der Arbeitsmappe in Excel.
2. Aufbereiten der Daten über diverse VBA-AddIns bzw. manuelle Berechnungen.

C: Mein Delphi-Programm (automatisch): Abgleich der Excel-Daten mit der DB.
1. Abholen von Auftraggeberdaten (z.B. Name, Adresse, Probenbezeichnung) aus der DB.
2. Abholen des Auftragumfanges aus der Oracle-DB, da das Meßgerät i.d.R. mehr Daten liefert, als der Auftraggeber verlangt.
3. Abholen der Daten aus Excel.
4. Markieren der gewünschten Daten in Excel und ggf. herausrechnen der nicht beauftragten Daten. (Ergebnisse nach Excel schreiben)
5. Ggf. verrechnen mit von anderen Meßgeräten in die DB geschriebenen Werten. (Ergebnisse nach Excel schreiben)
6. Gegenüberstellen der ermittelten Daten mit den gemäß DB verlangten Parametern für den Anwender.

D: Der Anwender in meinen Delphi-Programm: Logische Überprüfungen
1. Die automatischen Zuordnungen der Daten prüfen und ggf. korrigieren.
2. Evtl. Dimensionsumrechungen (z.B. g/L -> mg/L) durchführen lassen.
3. Prüfen, ob evtl. Grenzwertverletzungen real sind.
4. Freigabe der Ergebnisse

E: Mein Delphi-Programm (automatisch):
1. Die Daten werden in die DB geschrieben und auf dem in der DB hinterlegten Weg an den Auftraggeber übermittelt.
2. Die DB liefert für jede übermittelte Messung diverse Quittierungsdaten. Diese werden in die Excel-Mappe geschrieben.
3. Beenden meines Programmes.

F: Der Anwender: QS-Dokumentation.
1. Formatieren der Tabelle für den Andruck
2. Andruck der Excel-Tabellen mit allen Meß- und DB-Daten.
3. Unterschreiben und archiveren der Andrucke.


Bisher wir mein Programm über einen erstellten Menübefehl in Excel gestartet.

Bei der Überprüfung der Daten im Schritt D1 kann es vorkommen, das der Anwender mein Programm verläßt und ab Punkt B2 - mit den von der DB importierten Daten !!! - neu beginnt.

Gruß aus Köln
Thomas

[Chemiker]

Hallo ThoPos,

Ich gehe jetzt mal davon aus das Du keine Chance hast die Messwerte die in Excel geschrieben werden in Delphi direkt umzuleiten. Aber nach Punkt A: 3. wird das Workbook geschlossen und abgespeichert.

Ab B: würde ich mit Delphi die Kontrolle übernehmen und mit OLE-Automation weiterarbeiten.
Damit wird erreicht:
1. Das Dein Programm die Kontrolle behält.
2. Weiter Messungen ohne Beeinflussung der Vorgänger Messung durchgeführt werden kann, weil so wie ich es jetzt verstanden habe die Steuersoftware ja autonom handelt.

Für mich stellt sich eigentlich das größte Problem mit der Umsetzung der diversen VBA-AddIns in Delphi. Wenn Du sie selbst geschrieben hast und die Logik kennst, sollte es nicht zu schwer sein.

Meine persönliche Meinung von QS und Excel ist, dass sich das gegenseitig ausschließt. Ich weis nicht wie man eine vernünftige Validierung mit Excel hinkriegen soll, aber das ist wie gesagt meine persönliche Meinung(gestützt durch entsprechende Ehrfahrung).

Bis bald Chemiker

[globetrotter77]

Da kann ich dem Chemiker nur beipflichten!
Das Analyseprogramm Prog1 hat Daten über irgendeinen Input In1 (Messgeräte, Messfühler etc.) ermittelt und sie in eine Excel-Mappe übertragen, welche nun gespeichert und geschlossen ist. Das Format dürfte immer das gleiche sein, also ist eine automatisierte Weiterverarbeitung möglich.
Ok, wir haben also einen Output Out1 des Analyseprogramms, wie auch immer.
Der Name der Excel-Datei dürfte bekannt sein, und wenn das Analyseprogramm eine neue Datei erstellt, wird die auch einen neuen Namen bekommen, oder? (Ansonsten müsste man sie mit eindeutig gekennzeichnetem Namen einfach kopieren)
Der nächste Schritt ist, dass eben dieser Output Out1 zum Input In2 für das nächste Programm Prog2 wird, das wiederum einen neuen Output Out2 erzeugt. Aus QS-technischen Gründen empfiehlt es sich hier tatsächlich, eine neue Datei anzulegen, so dass die alte erhalten bleibt.
Das "nächste Programm" Prog2 ist jetzt ganz einfach dein Delphi-Programm, das dann auch alle anschließenden Arbeiten erledigen kann, und zwar am besten ohne Einflussnahme irgendwelcher Anwender.
Ich betone, alle Arbeiten!
Dazu gehören auch Schritte wie F1 und F2, also Formatieren und Ausdruck.
Wenn dann tatsächlich noch manuelle Eingriffe nötig sein sollten, muss man sich erst mal überlegen, wieso das so ist und ob es nicht möglich ist, in immer wieder gleicher Form darauf zu reagieren, sprich: zu programmieren.
Korrekturen während der eigentlich als automatisch konzipierten Bearbeitung sind mehr als kontraproduktiv, sondern dürften bestenfalls in einem weiteren Schritt in gut dokumentierter Form erfolgen.

So würde ich es machen, einfach Schritt für Schritt.
Auf keinen Fall so, dass sich die Programme gegenseitig aufrufen, da sind die Schwierigkeiten wirklich vorprogrammiert.

Weiß nicht, ob dir das weiterhilft, aber frag einfach nochmal nach, falls es nicht so sein sollte.

[ThoPos]

Hallo Chemiker, hallo Globetrotter77,

im Grunde kann ich Euch nur beipflichten:

1. Excel und QS -> ein Widerspruch in sich ...
2. Alles sollte aus Delphi heraus gesteuert werden ...

Aber leider scheint dies nicht zu gehen bzw. der Aufwand wäre zu groß. Und schließlich muß das arme Labor meinen Aufwand bezahlen.

Der Gerätehersteller verfolgt leider die Philosophie, daß alles in Excel gemacht werden soll. Die Steuersoftware macht wirklich nichts anderes als Steuern und dee nackten Meßwerte zu liefern. Dabei kennt die Software zwei Exportformate: eine Textdatei für alle Proben oder je eine Excel-Datei pro Projekt (Probenserie). In der Textdatei steht leider nur die Probennummer, aber nicht das Projekt und die Struktur der Textdatei ist auch eigenartig: eine Zeile pro Probe, einzelne Meßwertblöcke (Bezeichnung, Wert, Einheit) mit Semikolon getrennt, die Daten eines Messwertblockes mit Komma getrennt, manche Ergebnisse in Hochkommas, andere widerrum nicht. Somit ist ein Einlesen der Textdatei sehr mystisch. Alle Excel-Dateien werden in einem fest eingestellten Verzeichnis abgelegt und der Dateiname ist der Name des Projektes, ggf. um nicht für Dateinamen verwendbare Zeichen bereinigt.

Sämtliche Berechnungen werden über die zahlreichen AddIns, ebenfalls vom Gerätehersteller, durchgeführt: z.B. Kalibrierung (liniar, quatratisch oder exponentiell), Umrechnen des Meßwertes in eine Gehaltsangabe (Massenanteil, Massenkonzentration, etc.), korrigieren der Daten um andere Angaben, die den Meßwert beeinflussen, etc.

Die AddIns sind alle geschützt. Somit kann ich nicht nachsehen, wie die AddIns arbeiten. Und das Lösen einer exponentiellen Gleichung aus 8 Wertepaaren (Meßwert - Gehalt) in Delphi möchte ich mir wirklich nicht antun. Es gibt tatsächlich ein Element, das exponentiell ausgewertet wird.

Somit finde ich, die einfachste Lösung ist, den Anwender alles in Excel machen zu lassen und nur bei den Schritten (Daten aus DB holen, Daten in DB schreiben, Ergebnisse übermitteln) zu unterstützen. Das funktioniert bisher super und auch fehlerfrei. Sogar ein Kundenaudit wurde erfolgreich bestanden. Wäre da nicht das Problem, daß die Gerätesoftware im Hintergrund arbeitet und immer wieder eine weitere Excel-Instanz öffnet.

Gruß aus Köln
Thomas

[globetrotter77]

Zitat:

Die AddIns sind alle geschützt.

Das ist natürlich keine gute Voraussetzung, war aber zu erwarten.
In diesem Fall würde ich, auch wenn sich mir die Nackenhaare sträuben, entweder
a) Delphi außen vor lassen und alles in Excel erledigen. Man kann auch aus Excel heraus Daten aus der DB abfragen und wieder zurückschreiben.
oder
b) Delphi die Daten ermitteln lassen und die Kommunikation über eine/mehrere Zusatzdateien steuern, aber auf keinen Fall aus Delphi wieder Excel aufrufen ... das ist vergleichbar damit, sich am eigenen Schopf aus dem Sumpf zu ziehen.