Access-o-Mania

Ich weiß, Access ist nicht für Statistik entwickelt. Aber ich möchte über eine Abfrage Summen bilden und prozentuale Anteile berechnen, die dann in einem Diagramm ausgegeben werden.

Bitte nicht gleich druff hauen. Meine Idee ist:

(1) Eine Abfrage und ein HF mit einem Endlos-UFO, das auf der Abfrage basiert.
(2) in dem HF soll es ein Feld geben, in das man eine Zahl eingeben kann. Zum Beispiel "2017". Mit dieser Zahl wird dann ein Filter in der Abfrage angesteuert. Zum Beispiel werden dann nur DS aus 17 angezeigt.
(3) in der Kopfzeile des endlos-UFO's bringe ich Zählfelder unter, die auszählen, wieviele DS gerade angezeigt werden. Die werden dann vom HF ausgelesen.
(4) Damit steuere ich formularbasiert eine Formel an, die dann Werte ausgibt, welche zur Erstellung einer Graphik verwendet werden.

Haltet Ihr diesen Plan für umsetzbar und wenn nein, was würdet Ihr statt dessen empfehlen?

Carl

Hallo,

1) und 2) sind noch verständlich.

3) und 4) sind unklar, wie damit zu einem Diagramm zu kommen ist.



3)  Datensätze werden nicht anhand der Anzahl "ausgelesen", eher anhand eines Kriteriums selektiert (gefiltert). Das bedeutet, dass das HF auf einer Tabelle/Abfrage basieren muss, die die gewünschten Felder enthält, was ja dann mehr oder weniger identisch mit dem UFO wäre.

4) "steuere ich formularbasiert eine Formel an"   ?? 
       "die dann Werte ausgibt"   wohin ausgibt? 

Ein Diagramm hat in aller Regel eine Abfrage als Datenbasis (Rowsource). Insofern könnte gleich die für das UFO verwendete (und gefilterte) Abfrage für ein Diagramm dienen.

Also mit 3) habe ich Erfahrungen, das funktioniert problemlos. Man bringt im Formularkopf ein Zählfeld unter, dessen Wert dann im HF abgerufen wird. Damit kann man genau ermitteln, wieviele DS gerade aktuell angezeigt werden. (und somit auch gefiltert sind) Das ist notwendig, weil es auch formularbasierte Filter gibt, die also nicht auf eine Abfrage zurück gehen.

Das HF basiert nicht auf der Abfrage, nur das UF. Das HF filtert aber formularbasiert.

Ich brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht. Damit der User dort z.B. einen Zeitraum eingeben kann, nach dem gefiltert werden soll. Oder ein Textfeld, um z.B. alle einzuschließen, die mit "abc*" anfangen.

zu 4) Man kann in einem ungebundenen Feld etwas nach einer selbst geschriebenen Formel berechnen lassen, da sehe ich keine Probleme. In dem Feld steht dann einfach eine Zahl, z.B. 14 (Prozent). Diese Felder erzeuge man dann für alle Merkmalsausprägungen des gewünschten Kriteriums, so dass sie sich zu 100 summieren.

z.B. drei ungebundene Felder im HF
[erfolgreichbeendet] = 56
[abgebrochen] = 14
[nochimProzess] = 30

Allerdings weiß ich auch noch nicht, wie ich damit zu einem Diagramm kommen kann. Es müsste dann wahrscheinlich auch eine formularbasierte Graphik sein.

Kennt jemand eine beispiel-db, wo sowas mal behandelt wurde?

Carl

Hallo,

recht schwierig, dies zu verstehen...

3)   Was ist denn ein Zählfeld?   Ein Steuerelement mit Inhalt  =Anzahl(*)  Im Formularkopf des UFO's  ?

ZitatDas ist notwendig, weil es auch formularbasierte Filter gibt, die also nicht auf eine Abfrage zurück gehen.

Warum ist so ein "Zählfeld" notwendig?

ZitatDas HF basiert nicht auf der Abfrage, nur das UF.

Heißt das, es ist ungebunden? 

ZitatDas HF filtert aber formularbasiert.

??  Ein "formularbasierter Filter" (des HF) würde die im HF angezeigten Datensätze filtern.  Die gibt es aber nicht, weil es ungebunden(?) ist.

ZitatIch brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht.

Du brauchst also eine Referenz auf ein Steuerelement in der Where-Condition einer Abfrage?

Schreibe im Abfrageentwurf im Feld "Bedingung"   z. B. Forms![MeinFormular]![MeinTextfeld]
, um exakt zu vergleichen.

Bei einer Ähnlichkeits-(TeilString-) Überprüfung lautet die Bedingung dann so:

Wie "*" & Forms![MeinFormular]![MeinTextfeld] & "*"

Beim Vergleich am Anfang eines Textes:

Wie  Forms![MeinFormular]![MeinTextfeld] & "*"



4)  Selbstverständlich kann man in einem ungebundenen Form und mit Hilfe von Textfeldern Berechnungen durchführen.  Die Ergebnisse sind aber nur solange sichtbar, wie das Form geöffnet ist.  Welche Berechnungen hier durchgeführten werden sollen, ist zunächst unerheblich.



Es soll also ein Diagramm auf Basis dieser ungebundenen Eingabefelder und der daraus berechneten Werte erstellt werden?

Wie gesagt, benötigt ein Diagramm eine Abfrage in seiner Eigenschaft "Rowsource". Die Abfrage könnte aus den ungebundenen Steuerfeldern zusammengesetzt werden, sofern (nur) diese im Diagramm im HF (beim Klick auf "btnShowResult")  dargestellt werden sollen:

Sub btnShowResult_Click()
Dim strSQL as String
strSQL = "Select " & Me![erfolgreichbeendet] & " as Success, " & Me![abgebrochen] & " as Canceled, " & Me![nochimProzess] & " as InProgress   from [irgendeineTabelle]"
Me!MeinDiagramm.Rowsource = strSQL

End Sub

ZitatDiese Felder erzeuge man dann für alle Merkmalsausprägungen des gewünschten Kriteriums, so dass sie sich zu 100 summieren.

Dem kann ich immer noch nicht folgen..  ???

Zitat
3)   Was ist denn ein Zählfeld?   Ein Steuerelement mit Inhalt  =Anzahl(*)  Im Formularkopf des UFO's  ?

Ja.

Mit ihm wollte ich die Anzahl der formularbasiert gefilterten Datensätze zählen; also die, die gerade angezeigt werden.

Ich benötige keine Tabelle, um die Ergebnisse irgendwo abzulegen.

Zitat
Heißt das, es ist ungebunden? 

Ja, ich würde das HF ungebunden lassen. Warum soll man es an eine Tabelle binden, wenn es doch nur als Träger für die Filter und für die Anzeige der Ergebnisse benötigt wird.

Zitat

ZitatDas HF filtert aber formularbasiert.

??  Ein "formularbasierter Filter" (des HF) würde die im HF angezeigten Datensätze filtern.  Die gibt es aber nicht, weil es ungebunden(?) ist.

Ich mache ins HF ein UFO und das wird dann gefiltert.

Zitat

ZitatIch brauche also nur einen Filter in der Abfrage, der einen Wert aus einem ungebundenen Feld im Formular bezieht.

Du brauchst also eine Referenz auf ein Steuerelement in der Where-Condition einer Abfrage? Schreibe im Abfrageentwurf im Feld "Bedingung"   z. B. Forms![MeinFormular]![MeinTextfeld]
, um exakt zu vergleichen.

Referenz, okay! Ich setzt mich ran.

Carl

Ich hab nochmal ne Zwischenfrage zum Datenmodell.

gegeben ist eine Tabelle in der so "Kopfdaten" sind wie Name, Geburtsdatum, Geschlecht usw..

Wenn ich jetzt für z.B. einen dreijährigen Prozess 21 Datumsfelder habe, die in einer Excel-Datei neben einander stehen.

Soll man dann trotzdem die Datumsfelder in einer anderen Tabelle ablegen und nicht in die Tabelle mit den Kopfdaten anhängen? Und die Kopfdaten und die Datumstabelle in einer Abfrage zusammen führen als Grundlage für das Formular?

Warum? Damit sich die User seltener gegenseitig überschreiben?

Carl

Hallo,
wenn man es datenbankkonform/Regelgerecht macht, so gibt es eine Tabelle für die Kopfdaten und eine Tabelle zur Erfassung der Datumswerte, aber nicht mit 21 Feldern, sondern in einem Feld mit 21 Datensätzen. Die Tabelle braucht dann einen Fremdschlüssel zu den Kopfdaten.
Was wird denn noch zu einem Datum gespeichert, es wird ja bestimmt nicht nur das Datum erfasst.

Zitat von: MzKlMu am September 20, 2018, 19:24:04
Was wird denn noch zu einem Datum gespeichert, es wird ja bestimmt nicht nur das Datum erfasst.

Es wird noch für jedes Datum ein Checkkästchen benötigt, das angibt, ob der zum jeweiligen Datum fällige Vorgang erfolgt ist.

Damit verstehe ich aber noch immer nicht, was der Nachteil wäre, wenn man alle Datumsfelder in die Kopfdatentabelle bringt.

Die Anzahl der Datumsfelder ändert sich nie.

Carl

Hallo,

ZitatEs wird noch für jedes Datum ein Checkkästchen benötigt, das angibt, ob der zum jeweiligen Datum fällige Vorgang erfolgt ist.

Dann fehlt noch eine Tabelle für die Vorgänge und in die extra Tabelle muss dann ein Fremdschlüssel zum Vorgang. Das wäre dann eine n:m Beziehung zwischen Vorgang und Kopfdaten.
Das Datum, ist das dann das Erledigungsdatum, wenn ja, entfällt auch das Ja/Nein Feld.

Zitatwenn man alle Datumsfelder in die Kopfdatentabelle bringt.

Dann versuche mal in einer solchen Tabelle das höchste Datum zu finden

Zitatich möchte über eine Abfrage Summen bilden und prozentuale Anteile berechnen

Das geht prinzipiell. Was Du da mit Formularen veranstaltest, ist unklar.
"über eine Abfrage" ist wohl nur so gesagt oder gelogen?

Also ja! Es ähm war gelogen!

Über eine Abfrage, weil die Ergebnisse ja dynamisch angezeigt werden und nicht gespeichert werden sollen. Und formularbasiert, weil die Anwender anschaulichen denken. (what you see is what you get) Es kann da schon mal vorkommen, dass einzelne DS auf Formularebene ausgeblendet werden sollen, um die Statistik zu "schönen". Das ist nicht meine Sache, aber bei Excel ist das natürlich super leicht möglich. Und wenn beim Übergang zu Access diese Möglichkeit nicht verfügbar ist, sinkt die Akzeptanz. Dann wird die DB nur ungern angenommen. Man sagt dann, Access sei nicht so gut und überhaupt. Die wollen dann plötzlich kein Access mehr. ...



Carl

Ich habe nochmal eine Frage an Klaus wegen dem Datenmodell:

Ich habe eine Tabelle "Kopfdaten", in der jeder DS einen Vorgang  darstellt und in dem Kopfdaten stehen. Und dann sollen zu jedem DS in dieser Tabelle 21 Datumsfelder + zu jedem dieser Felder ein chckkästchen, ob der Vorgang erfolgreich war.

Es kann niemals vorkommen, dass ein Vorgang mehr oder weniger als diese 21 Daten erfordert. Zum Beispiel wird kein Vorgang mehrfach durchlaufen.

Meine Frage:
Habe ich das richtig verstanden, dass man trotzdem für diese Datumsfelder eine zweite Tabelle anlegen soll? Zum Beispiel um Bearbeitungskonflikte zu vermeiden? Also es gibt immer nur eine 1:1-Zuordnung wie in einer langen Zeile einer Excel-Tabelle, nie beispielsweise mal ein wiederholtes Ausfüllen für den selben Vorgang.

Ich meine ich hätte nichts gegen eine zweite Tabelle für die 21 Felder, aber wie kann man gewährleisten, dass in dieser zweiten Datums-Tabelle immer auch ein DS angelegt wird, wenn in der Kopfdatentabelle ein neuer DS hinzu kommt?

Carl

Zu dem Wie: könnte man in Access-Versionen >= 2010 ein After Insert Datenmakro beauftragen, 21 Datensätze in einer anderen Tabelle anzulegen, die alle als Fremdschlüssel den Wert des Primärschlüssels des neu angelegten Datensatzes erhalten. In niedrigeren Versionen ohne Datenmakros kann man das Gleiche über Formularsteuerung erzwingen, indem man im Nach Einfügen Ereignis des Formulars das Erstellen z.B. durch Ausführen einer Anfügeabfrage anleiert.

Hallo,

m. M. nach sollte erst die Bedeutung dieser 21 Datumsfelder geklärt werden.

DB-gerecht und beziehungsgerecht wäre, für jeden Vorgang  (tblVorgaenge) in einer Detailtabelle (tblVorgangDetails) mit 1:n-Beziehung  jeweils nur dasjenige Datum einzutragen  (hinzuzufügen), an dem der Vorgang erfolgreich war.


In diesem Kontext ist nicht zu verstehen, warum es 21 Termine geben sollte, die "Vorgang erfolgreich" definieren können (sollen).

Vermutlich soll aber das Datumsfeld  unterschiedliche Vorgangsdetails   entspr. kennzeichnen.  In diesem Fall wäre in tblVorgangdetails auch nur (neben den Schlüsselfeldern) eine Bezeichnung des Vorgangdetails (evtl. weiter normalisiert mit einer Tabelle "tblDetails", in der alle möglichen "Vorgangsdetails" hinterlegt sind und wiederum über die Schlüsselfelder in Beziehung zu tblVorgangDetails steht) und ein Datum(sfeld) erfolderlich.  Ein "Haken" ist überflüssig.


Sind die Datumsfelder und die "Haken" (die ohnehin überflüssig sind. Ein leeres Datumsfeld ist gleichbedeutend mit "erfolglos") nur zur "Ansicht " gut, soll heißen, es wird mit diesen Feldern keine weitere Analyse, bzw. Berechnung durchgeführt, könnten diese 21 Datumsfelder (weil unveränderlich in ihrer Anzahl und ihrer einzelnen Bedeutung) auch direkt in tblVorgaenge bleiben.

Hallo,
wie Franz schon sage, sollte die Bedeutung der 21 Datumsfelder geklärt werden.
Nenne mal ein paar Beispiele für die Namen der 21 Felder ?
Wahrscheinlich fehlt hier noch eine weitere Tabelle in der die Bedeutung der 21 Felder als je ein Datensatz erfasst ist, damit hier eine n:m Beziehung mit 3 Tabellen aufgebaut werden kann.

Also ein Datumsfeld erfasst einen Stichtag im Prozess, an dem eine Messung vorgenommen wird. Alle 21 werden (über 3 Jahre) zu jedem Prozess und immer der Reihe nach ausgefüllt. Wenn Datum1 verstrichen ist, wird die Messung vorgenommen und danach wird je nach Prozess-Typ das nachfolgende Datum2 ausgefüllt. Wenn Datum2 heran ist, wird erneut gemessen, und Datum3 bestimmt. Bis zum Datum21. Das Messergebnis hat keinen Einfluss auf das nächst folgende Datum. Die Datumsfelder sind dazu da, dass der jeweilige MA weiß, wann er messen soll. Bzw. welche Vorgänge er heute alle messen soll. Das Datumsfeld muss also in jedem Fall ausgefüllt werden.

Jedes Datumsfeld hat ein beigeordnetes checkkästchen , das "=wahr" wird, wenn die Messung ein erfolgreiches Ergebnis ergab und dass "=falsch" bleibt, wenn die Messung nicht erfolgreich war. Unabhängig von den Messergebnissen werden alle nachfolgenden Datums abgerastert, bis man nach 3 Jahren bei der 21 angekommen ist und der Prozess beendet ist. Es kann aufgrund des Prozesses nie zum Überspringen oder zu zusätzlichen Datum kommen.

Die Daten müssen niemals sortiert werden und es steht schon fest, dass sie immer wie beim Kalender von früher zu später laufen. Der Abstand der Datums hat keinen Informationswert.

Die Kopfdaten sind ca. 30 Felder, d.h. die tblKopfdaten würde auf 80 Felder ansteigen, wenn die Daten und deren checkkästchen mit hinein sollen.

Carl

Hallo,
das wonach ich gefragt habe hast Du nicht gesagt.

ZitatNenne mal ein paar Beispiele für die Namen der 21 Felder ?

DatumStart_ICF
Datum_Start_LUV
Datum_Start_PSE

Datum_PBZ_GESP
Datum_PBZ_FPLLUV
Datum_PBZ_Ber

Datum_E1AJ_1VG
Datum_E1AJ_FPLLUV
Datum_E1AJ_PSE

--------und dann natürlich die chckkästchen----

DatumStart_ICF_chk
Datum_Start_LUV_chk
Datum_Start_PSE_chk

Datum_PBZ_GESP_chk
Datum_PBZ_FPLLUV_chk
Datum_PBZ_Ber_chk

Datum_E1AJ_1VG_chk
Datum_E1AJ_FPLLUV_chk
Datum_E1AJ_PSE_chk

usw.

Ich könnte sie auch durchnummerieren von Datum_I bis Datum_XXI

Carl

Hallo,

noch eine Frage:

Zitatdanach wird je nach Prozess-Typ das nachfolgende Datum2 ausgefüllt

Woher weiß man dieses nachfolgende Datum? Wie lautet der Algorithmus?

Was ist der Prozess-Typ und wo ist der definiert?



Ich tendiere zu der normalisierten Lösung:

In Tabelle "tblVorgangDetails"  (--> "tblVorgangMessungen") das Datum und den Typ einer Messung (zum Vorgang)  erfassen und  anhand des Algorithmus das nächste Messdatum als Standardwert berechnen.

Das nachfolgende Datum hängt unter anderem vom Prozess-Typ ab (da gibt es 4 verschiedene und die sind auch pro Region, in der der Auftraggeber sitzt etwas unterschiedlich usw.), von den vertraglich vereinbarten Wünschen des Auftraggebers, da gibt's viele verschiedene usw.. Außerdem ändert sich das manchmal, so dass man zur Ermittlung des nächsten Datums eine menschliche Entscheidung braucht und keine Generierung. Es gibt aber immer genau ein richtiges Datum, alle anderen wären falsch.

Der jeweilige MA schaut dann auf den Plan und weiß, welche Prozesse er in dieser Kalenderwoche messen soll. Und wenn er es gemacht hat, macht er ein Häkchen und bestimmt das nächste Datum zur "Wiedervorlage". Die Prozesse sind individuelle Entwicklungen und dafür gibt's gerade eine Excel-Datei, die aber den Nachteil hat, dass dort die "Kopfdaten" händisch eingepflegt werden müssen, die der MA zur Begutachtung des Prozesses braucht.

Also Du würdest 2 Tabellen anlegen? Wie kann man dann sicher stellen, dass es in der 2. Tabelle immer genau einen DS gibt, der mit einem DS der ersten Tabelle korrespondiert?

Carl

Hallo,
Du hast meine Frage immer noch nicht beantwortet. Ein Datum braucht doch ein Bezug zu einem Ereignis. Und der ergibt sich über den Feldnamen und daher wollte ich einfach mal einige Feldnamen wissen, der Felder die das Datum enthalten. Die müssen doch einen Namen haben, oder heißen die Datum1, Datum2, .... Datum21 ?

ZitatWie kann man dann sicher stellen, dass es in der 2. Tabelle immer genau einen DS gibt, der mit einem DS der ersten Tabelle korrespondiert?

Diese Annahme ist falsch. In der 2.Tabelle muss es 21 Datensätze geben und nicht nur einen, denn es gibt dann ja nur noch ein Datumsfeld und jedes Datum steht in einem Datensatz.

Zitat(da gibt es 4 verschiedene und die sind auch pro Region, in der der Auftraggeber sitzt etwas unterschiedlich usw.),

Und das ist auch ein Problem. Die Zusammenhänge Prozess und Region müssen auch in einer Tabelle abgebildet werden.
Da liegt vieles noch im Argen fürchte ich.

okay, ich verstehe, Du würdest in der Datumstabelle ein Feld mit 21 Datensätzen anlegen.

Ein Feld heißt jetzt beispielsweise "Datum_E1AJ_1VG", aber mir ist es egal, wie die Felder heißen.

zu Deiner Dritten Anmerkung: das nächste Datum muss per Hand vom MA festgelegt werden, alles andere würde mehr Wartungsaufwand als Nutzen erzeugen. Der MA kann das innerhalb weniger Sekunden erledigen und schlägt den Nutzen einer Automatisierung bei Weitem.

Carl

Hallo,
die nachfolgenden Feldnamen sind ja Abkürzungen (nach Datum).
Könntest Du das als Klartext übersetzen, also so:
Start_ICF = Start ? ? ? ?
usw. für nachfolgende Felder:
DatumStart_ICF
Datum_Start_LUV
Datum_Start_PSE
Datum_PBZ_GESP
Datum_PBZ_FPLLUV
Datum_PBZ_Ber
Datum_E1AJ_1VG
Datum_E1AJ_FPLLUV
Datum_E1AJ_PSE

Das bräuchte ich, um einen Vorschlag zum Aufbau machen zu können.

Zitatdas nächste Datum muss per Hand vom MA festgelegt werden,

ja, ich habe auch nichts gegenteiliges geschrieben. Ich habe auch nichts von einer Automatisierung geschrieben.
Ich will die Zusammenhänge zwischen Prozess und Region in einer Tabelle erfassen, damit klar ist welcher Prozess für welche Region zutreffend ist.
Und dazu noch eine Frage:
Wenn die Prozesse von der Region und/oder Kunde abhängig sind, wieso sind das dann immer 21 Datumsfelder, also auch immer genau 21 Prozesse ?

Es muss jeweils bis zu einem bestimmten Tag nach Beginn des Prozesses ein jeweiliges Gutachten (basierend auf der Messung) abgegeben werden, für das die Abkürzung steht. Die Datums sind von Region und Kunde abhängig. (Region = Bundesland und deren jeweilige Bestimmungen) Dass es 21 sind, ist von der Excel-Tabelle vorgegeben, weil sich offenbar damit jede mögliche Verlaufsdokumentation abdecken lässt. Wenn beispielsweise ein Kunde zum Datum 12 kein Gutachten wünscht, dann muss zu diesem Zeitpunkt aber die Messung dokumentiert werden und dass aber kein Gutachten übermittelt wurde. Der Prozess läuft ja weiter und nach 3 Jahren ist nachzuweisen, dass man ihn durchgehend betreut hat. Dafür hat man offenbar 21 Messgelegenheiten als ausreichend definiert.

Die Abkürzungen LUV, PSE usw.. sind Bezeichnungen für Verwaltungsakte, für die die jeweilige Messung (Begutachtung) gebraucht wird. Die bezeichnen auch einen Typ Gutachten, was der MA dann automatisch weiß. Es kann aber sein, dass der Verwaltungsakt im Einzelfall einfach ohne das Gutachten gemacht wird. Es gibt viele Sonderwünsche und Ermessens-Termine, die sich auch mit den Jahren verändern können. Wichtig ist immer nur, dass keines der eingetragenen Daten untätig vergessen wird. Es muss sich sozusagen eine grüne Zeile ergeben, damit der MA das Gefühl bekommt, dass alles erledigt ist. So hat man es eintradiert.

Carl

Hallo,
dass man bei Dir immer mehrfach um Antworten bitten muss, kann ich nicht verstehen.
Ich wollte den Klartext haben zu den Kürzeln (LUV, PSE usw.)

Zitat von: MzKlMuKönntest Du das als Klartext übersetzen, also so:
Start_ICF = Start ? ? ? ?
usw. für nachfolgende Felder:

Siehe meinen vorherigen Beitrag.
Ich denke mir doch was bei meinen Fragen und will Dir einen vernünftigen Vorschlag machen, der nicht abstrakt sondern real ist.
Also bitte, bemühe Dich mal.


PS:
Mit der Strukturänderung hätte sich auch die 2. Designfrage erledigt, denn das seitwärts scrollen ist dann nicht mehr nötig.

"ICF_Start" ist einfach das Gutachten "ICF" zum Start des Prozesses. Ich kenne mich damit auch nicht aus. Es steht so in der Excel-Datei.

Der Start dauert 6 Wochen und innerhalb dieser sind die Messungen ICF, PSE und LUV vorzunehmen und zu begutachten.

Das Problem ist, dass das frm möglichst so wie in Excel aussehen soll, damit es gut angenommen wird. Es soll also sidescrollen, das ist ne Vorgabe. Ansonsten hätte ich einfach breitere Kacheln mit einem Listenfilter gemacht. Aber nein ...

Carl

Hallo,

ZitatIch kenne mich damit auch nicht aus.

und dann machst Du eine Datenbank ?

Der Wunsch nach dem Aussehen wie Excel ist konträr zu einer Datenbank.
Eine Datenbantabelle hat bei richtigem Aufbau mit einer Exceltabelle nichts gemeinsam.

An der Stelle kann ich nichts mehr dazu beitragen. Meine Vorschläge erstellen eine ganz andere Ansicht.
Wobei ich davon überzeugt bin, wenn man das mal den Anwendern zeigen würde, würde kein mensch mehr Excelaussehen verlangen.

Hallo Carl,

ZitatIch kenne mich damit auch nicht aus.

Schlechte Voraussetzung. Was ich hier so gelesen habe, denke ich, dass
sogar ein Profi an dieser DB zu knabbern hätte.
Der würde sich aber wohl auch zuerst mit dem Auftraggeber zusammen
setzen, sich die Prozesse/Abläufe erklären lassen und ein Pflichtenheft
erstellen.
gruss ekkehard