Variable Spaltenüberschriften in einer Ansicht ???

[eknori]

welches aus dem ersten importierten Datensatz stammt.

Die Informationen kann man sich beim Import doch gleich in einer Liste merken. Erster Dtensatz = ab in die Liste. Dann den Rest importieren

[koehlerbv]

Deswegen schrieb ich ja "am besten vor dem Import": Also erste Zeile lesen (und merken oder gleich die ColumnTitles setzen), diese Zeile verwerfen und ab der zweiten Zeile den eigentlichen Import starten.
Damit dürfte dann aber die externe Datenpumpe überfordert sein. Den Import auch noch selber zu machen, kann ja aber nicht der Hit sein.

Bernhard

[Peter Klett]

Nun bin ich wieder genau so weit, wie am Anfang, ich versteh' das Problem nicht.

Es sollen jetzt also nicht 100 verschiedene Tabellen, sondern nur 10 importiert werden, das ganze dann 12 mal im Jahr macht 120 (ist logisch). Alle Tabellen sollen in eine Datenbank gestopft werden, für jede Tabellenart gibt es eine eigene Maske, eine eigene Ansicht, eine eigene Gliederung usw.

Wenn jetzt eh schon für jede Tabellenart alles nochmal gebaut werden soll, wo ist dann das Problem, in jeder Ansicht je Tabellenart die Spaltentitel fest zu definieren?

Das ganze Konstrukt ist mir viel zu starr aufgebaut. Kommt eine neue Tabellenart dazu, muss das, was schon 10 mal existiert, ein elftes Mal gebaut werden. Verschwindet eine Tabelle, kann sie aber wegen der Aufbewahrungspflicht nicht einfach entfernt werden. Schön ist das alles vielleicht beim Inbetriebnehmen, mit zunehmender Dauer und natürlich kommenden organisatorischen Änderungen wird das Ding immer krautiger. Werden Änderungen in den Ansichten gewünscht (Schaltflächen, vielleicht eine weitere Ansicht nach Status u.a.), muss immer alles mehrfach umgesetzt werden. Da fallen mir bestimmt noch mehr negative Punkte ein, wenn ich länger drüber nachdenke.

Als fanatischer Verallgemeinerer würde ich eine Tabellendatenbank bauen, die EINE Tabellenart verarbeiten kann. Je Tabellenart wird dann eine Tabellendatenbank angelegt. In den Tabellendatenbanken können Verlinkungen über die zentrale Definitionsdatenbank zu den anderen Tabellendatenbanken (natürlich dynamisch, nicht hart gecodet) eingebaut werden. Für den Anwender macht es dann keinen Unterschied, ob er in der Gliederung eine andere Gliederung oder eine andere Datenbank aufruft.

Kommen dann noch Spezialanforderungen zu einzelnen Tabellen dazu (z.B. kleine Workflows zu einzelnen Datensätzen), können die auch wieder allgemeingültig gebaut werden, so dass sie in jeder Tabelle verwendet werden könnten, und falls nicht benötigt, werden sie dann per Konfiguration verborgen. Entscheidend ist, dass jede Funktion und jede Erweiterung nur einmal gebaut werden muss.

Nur in solch einer Struktur ist es m.E. sinnvoll, darüber nachzudenken, wie man Spaltentitel berechnen kann. Und um das Vererbungsproblem durch die Schablonen zu beseitigen, könnte man in die Definitionsdatenbank eine Aktion einbauen, die in allen Ansichten der Tabellendatenbanken den Gestaltungsschutz ein- und ausschalten kann. Beim Update dann ausschalten, Designtask laufen lassen, Schutz wieder einschalten und Titel neu rechnen lassen.

So wird dann aus dem einmalig einsetzbaren Projekt "Verwalte 10 Tabellenarten" das universell einsetzbare Produkt "Verwalte beliebige Tabellen".

Den Import würde ich auch selbst bauen, das ist wirklich kein Hexenwerk. Die Dateien aus IDA (IDA ist Cognos ReportNet, inzwischen zugehörig zu IBM (?)) mögen zwar die Endung "xls" haben, sind aber nur csv-Dateien. Wir importieren solche Listen täglich mit eigenen Routinen. Der Vorteil bei der eigenen Routine besteht einmal darin, dass, wie auch schon von Bernhard genannt, die erste Zeile als Spaltendefinition gelesen werden kann, und dass eine Listendefinition nur einmal hinterlegt werden muss. Sonst muss sie einmal für die ListenDB und einmal für die Pumpe hinterlegt werden. Zweimal die selben Daten erhöht sowohl Verwaltungsaufwand wie auch Fehlerhäufigkeit.