Office: (Office 2003) Neu-Erstellung Datenbank- sinnvolle Aufteilung einer importierten Excel-Tabelle

Hallo Leute.
Brauche eure Hilfe.

Dazu muß ich folgendes erklären.

Es geht um eine Datenbank für einen Fuhrpark, bei dem festgehalten werden muß, wann, mit welcher Auftragsnummer, welche der Reifen der Zugmaschine ( insgesamt bis zu 8) und des Aufliegers ( 6 Reifen) gewechselt worden sind, wie hoch die Laufleistung war und welche Arbeiten ( Radwechsel, Auswuchten, Montage, Altreifenentsorgung usw.) erledigt wurden.

Dies wurde bisher in einer Excel-Tabelle festgehalten.
Allerdings mußte dann immer, wenn ein Bericht daraus erstellt werden mußte,
alles doppelt und dreifach getippt werden.

Ich habe zwar schon ein paar Datenbanken erstellt, aber hier beiße ich mir die Zähne schon an dem Grundaufbau - in welche Tabellen unterteile ich diese über 100 Spalten umfassende Excel-Tabelle auf, und in welche Beziehung stelle ich sie zueinander, damit nachher auch richtige Ergebnisse dabei rauskommen.

Die zu Grunde liegende Excel-Tabelle habe ich als Anhang beigefügt.

Es wäre nett, wenn ihr vielleicht mal schaut, ob ihr da helfen könnt.

Mein Hauptproblem ist es, die Beziehungen und die Aufteilungen für die ganze Sache hinzubekommen.

Am coolsten wäre natürlich ein Grundaufbauschema bzw eine Beispieldatenbank.

Vielen Dank im Voraus

mlceagle

:)

 

Um die Sache besser verstehen zu können, wären noch ein paar Erläuterungen deinerseits sinnvoll.

Was bedeutet:

Spalte - Titel
H - Anzahl
L - Pos1 und M - Grund1 (gilt ja dann wohl für alle 14)
CL - AV
DJ - KK

Noch ein paar Fragen:

Ist es richtig dass ...
- jedes Fahrzeug eine eigene und eindeutige Kostenstelle hat?
- es immer nur eine Reparatur der Zugmaschine ODER des Aufliegers gibt (und nicht auch mal BEIDE zugleich repariert werden müssten?)

- Was wäre für dich die "Haupttabelle" bzw. ein sinnvoller Name dafür: tblVorgaenge oder tblAuftraege oder ???

- was bedeutet die Spalte "Rechnungs-Nr" und was "Vergölst Rechnung Nr"; sind das Kosten, die dem Fuhrpark in Rechnung gestellt werden oder stellt sie der Fuhrpark irgendwem in Rechnung?

Bernd

 

Hallo

Danke für das Interesse


in Spalte H wird die Anzahl der erneuerten Reifen eingetragen.
Die Position ( welcher Reifen wurde erneuert ?) erkennt man an der Spalte, hinter der Pos bei Grund ein Grund für den Reifenwechsel eingetragen ist (z.Bsp: bei Vorgang MF1000 hinter Pos 1 ( o mm ) Grund V = Verschleiß

Alle Reifen werden bei jedem Fahrzeugkontakt komplett eingemessen.
Die mm-Angaben werden bei den Pos1 bis Pos14 eingegeben. (Spalte L usw.)

Eine Spalte hinter der Pos1 bis Pos14 wird bei den Reifen, die erneuert wurden, der Grund für die Erneuerung eingetragen ( V-Verschleiß) (BS - Bremsstelle usw.)

Spalte CL (AV) bedeutet Altreifenvernichtung bzw. Altreifenentsorgung.

Spalte DJ ( KK) bedeutet Karkassenankauf - bedeutet, daß dort immer die Anzahl der erneuerten Reifen dem Reparaturdienst in Rechnung gestellt wird,da die abmontierten Reifen im Normalfall noch Geld wert sind.

Es ist richtig, das jedes Fahrzeug eine eigene Kostenstelle hat.

Theoretisch kann an einem kompletten Zug sowohl an der Zugmaschine als auch an dem Auflieger gleichzeitig eine Reparatur stattfinden.
Es gibt dann jedoch für jedes Fahrzeug trotzdem einzeln eine eigene Auftrags- und Vorgangsnummer.

tblAuftraege wäre ok.

Die Spalte Rechnungs-Nr wird vom reparierenden Betrieb an eine Zentralstelle (Vergölst) berechnet.

Die Vergölst Rechnungs-Nr wird nach Eingang der Rechnung des reparierenden
Betriebes erstellt und an die Flotte ( dem Fuhrpark ) ( Standorte - Seefeld usw) weiterberechnet.


Ich hoffe, das ich weiterhelfen konnte.

Vielen Dank schon mal im Voraus für die weitere Hilfe

mlceagle

 

Nur zur Zwischeninformation *Smilie

Tagsüber kann ich nicht so viel an deiner DB machen, doch denke ich, dass ich es heute abend fertig kriege.

Noch eine Frage:
Hören die Felder "KK" und "Betrag" zusammen, nach dem Motto:
- ein Einzelpreis beträgt z.B. 9 Euro,
- somit steht in KK die Zahl 2
- und in Betrag dann 18 Euro

Bernd

 

Hallo

Ja, ist richtig so.
Allerdings habe ich gerade gesehen, daß die Werte pro Karkasse unterschiedlich sind.
Also müßte das Feld - Betrag für Gutschriften Karkassen - (Betrag) frei einzugeben sein.

Vielen Dank schon mal

mlceagle

 

So, anbei ein erster Versuch.

Bitte bedenke, dass ich natürlich nicht annähernd in euren Vorgängen drinstecke und insofern sehr leicht bei der Strukturierung der DB noch Denkfehler drin sein können.

Darum hier auch eine ausführliche Beschreibung meiner Annahmen, damit du vielleicht schon auf Anhieb sehen kannst, wo ich irgendwas Falsches voraussetze.

Je nach deinen Antworten würde ich dann ggf. nochmal umstruktieren, ergänzen etc. – die hier gezeigte Modellierung muss also noch nicht die endgültige sein.

Allgemein
- Wie du siehst, habe ich bei vielen Feldbezeichnungen die in der Excel-Tabelle vorhandenen Leerzeichen gelöscht (statt „Reifen Nr Alt 1“ nun „ReifenNrAlt1“ – das erspart dir beim eventuellen späteren Programmieren viel Arbeit.

- Im Beziehungsfenster tauchen bei weitem nicht alle Tabellen auf, die ich erstellt habe. Die übrigen Tabellen sind sog. „Nachschlage-Tabellen“.
Wenn du willst, kannst du diese Tabellen schon auf Tabellenebene einbinden. So könntest du – z. B. - in der tbl_FAHRZEUGE aus dem Feld „ReifGroesseID“ ein Nachschlagefeld machen und dort die tbl_Reifengroesse einbinden. Ich mache das aber meist erst auf Formularebene.

Fahrzeuge
- Du schreibst, dass immer nur eine Zugmaschine ODER ein Auflieger repariert wird und die dann auch unterschiedliche Auftragsnummern erhalten. Somit kann man db-technisch die beiden als unterschiedliche Fahrzeuge betrachten.

- Also gibt es eine tbl_Fahrzeuge mit den mehr oder minder unveränderlichen Daten zum betreffenden Fahrzeug (insofern ist auch das später eine „Nachschlage-Tabelle). In dieser Tabelle muss ein Fahrzeug zunächst erfasst sein, ehe man es in der Tabelle Auftraege anzeigen kann.

- Es wäre zu überlegen, ob man noch in einem Feld auf den „Partner“ hinweist (also bei der Zugmaschine auf ihren Auflieger und umgekehrt – falls das immer die selben sind???)

- Selbstverständlich kann man später mal pro Fahrzeug in einem Formular und/oder Bericht auch soetwas wie eine „Reparatur-Historie“ anzeigen, in dem dann pro Fahrzeug alle Aufträge aufgelistet werden (siehe unten).

Deine „Päckchen“
- In dem Excel-Datenblatt sieht es ja so aus, als würden die jeweils 5 Felder von „Pos“ – „Reifen Nr Neu“ zusammen gehören und insgesamt halt 14 mal vorkommen. In der DB ist das in zweifacher Hinsicht anders:
a) gemäß deiner vorletzten Antwort werden immer ALLE Reifen vermessen
b) wie oben schon ausgeführt gilt eine Zugmaschine genauso als Fahrzeug wie ein Auflieger und pro Auftrag wird immer nur ein Fahrzeug repariert. Also gibt es jetzt nur noch max. 8 Reifen pro Fahrzeug.

- Aber, während bei jedem Auftrag ALLE Reifen vermessen werden (Pos1 – Pos6 / Pos8), ist offenbar bei den anderen 4 Feldern nur bei Bedarf ein Eintrag.

- Somit gehören die Pos1 – Pos8 in die tbl_Auftraege, während die anderen Felder in eine neue Tabelle gehören. Mir fiel kein besserer Name ein, also habe ich sie tbl_Raeder genannt. Das ist dann aber zwischen den beiden Tabellen eine M:N-Beziehung, daher braucht man noch eine Zwischentabelle.

- Ich weiß nicht, ob man für die Felder „ReifenNrAlt“ und „ReifenNrNeu“ auch soche Nachschlage-Tabellen anlegen kann wie für die Felder „Grund“ und „Profil“ – das weißt du besser.

Aufträge
- Neben den üblichen Daten wie Vorgang, Auftragsnummer etc. sind auch andere Daten, die man vielleicht zunächst dem Fahrzeug zuordnen würde, auftragsbezogen, wie z. B. der km-Stand usw.. Weiterhin – wie beschrieben – die 8 Felder Pos1 – Pos8.

- Wie vermutet, gehören die Felder KK und Betrag im Prinzip zusammen und du hast auch bemerkt, dass man noch einen frei eintragbaren Einzelpreis verwenden sollte. Meine Vermutung ist, dass es nicht so sehr viele verschiedene Einzelpreise gibt und darum habe ich sie auch mal ein eine Nachschlage-Tabelle gepackt. Ggf. musst du das Feld EPID noch in ein einfaches Feld zurückverwandeln und die tbl_EinzelpreisKarkasse löschen.
KK x Einzelpreis ergibt dann den Betrag
(wobei Betrag nur noch ein berechnetes Feld einer Abfrage ist).

Berechnete Felder
- Die Felder „Gesamtpreis EBtrans Netto“ und „Betrag Lieferant Netto“ sind, genauso wie „Betrag“, berechnete Felder, die du nur in der Abfrage erzeugst, nicht in der Tabelle.
Das habe ich jetzt noch nicht gemacht und somit tauchen diese Felder auch noch nicht im Formular auf.

Formular(e) „Fahrzeuge“
- Du siehst, dass es das Formular „Fahrzeuge“ im Grunde zweimal gibt. Das frm_Fahrzeuge dient zur Dateneingabe aller Fahrzeuge, während das sfrm_Fahrzeuge lediglich dazu dient, die Fahrzeugdaten im Formular Aufträge anzuzeigen (und deshalb auch etwas anders gestaltet sowie gesperrt ist).

Formular „ReparaturHistorie“
- Andeutungsweise habe ich dir mal was gebastelt, was natürlich noch vielfältig änder- und erweiterbar ist.

Formular „Auftraege“
- Das gelbe Feld „Fahrzeug suchen“ ist etwas tricky – es besteht aus zwei Feldern (der graue Teil ist ein eigenes Feld).

- Ich weiß ja nicht, um wieviele verschiedene Fahrzeuge es geht, darum ist diese Form des Fahrzeugsuchens vielleicht auch nicht praktikabel, zumal es keine echten Fahrzeugnamen gibt. Am ehesten kann man sie ja nach dem Kennzeichen oder der Kostenstelle suchen. Insofern müsste da vielleicht noch ein wenig im Suchfeld umgestellt oder eine andere Form von Suchfeld erzeugt werden. Wichtig wäre zunächst, dass du mal schreibst, um was für eine Zahl von Fahrzeugen (Zugmaschinen wie auch Auflieger) es hier geht.

- Wie du siehst, habe ich zur Bewätligung der Datenmengen ein Registersteuerelement verwendet, jedoch ist die Aufteilung der Felder sicher noch verbesserungswürdig – das sollte ja eine deiner leichtesten Übungen sein.

- Weiter oben habe ich schon geschrieben, dass die drei berechneten Felder, die du in der Abfrage erstellen musst, noch im Formular fehlen.

- Viel wichtiger als alles andere ist natürlich die Frage, ob die Aufteilung der DB jetzt schon richtig ist und deshalb das Formular auch so funktioniert, wie du es brauchst. Darum habe ich zwar schon all die Nachschlage-Felder (Kombifelder) an ihre Tabellen gebunden, jedoch ansonsten mehr „Sparprogramm“ gefahren.

- Sicherlich müsste es auch noch zumindest ein Suchfeld für die Aufträge bzw. Vorgänge geben, denn mal will ja nicht immer „durchblättern“. Aber das macht erst Sinn, wenn die Struktur als solche o.k. ist.


Tja, dann bin ich mal gespannt, ob das Ganze zumindest in etwa deinen Vorstellungen entspricht.

Übrigens, ich werde in der Regel immer erst abends zur Beantwortung von Fragen etc. kommen.

Bernd

 

Suuuper

Bin gerade erst auf diese Site gegangen.
Werde mir das Ganze mal zu Gemüte führen.
Vielen - vielen-vielen Dank schon mal.

Melde mich nach Durchsicht nochmal



mlceagle

 

So, habe mir deinen Entwurf angeschaut und versucht, ein paar Datensätze einzugeben.

Erst einmal vielen Dank für die bis jetzt schon investierte Zeit.

Nun zu der DB

Besonders gut finde ich die Idee mit dem Steuerregister- spart viel Platz.
Frage dazu: Wenn ich im Register Dienstleistungen z.Bsp. 2 Radwechsel eingebe und diese später mit Preisen hinterlegt sind, wird dann direkt im Register Finanzen unter dem Punkt-Dienstleistungen der Gesamtpreis wiedergegeben oder war diesw so nicht vorgesehen.
Wenn eine Berechnung vorgesehen war, klappt das dann ohne Schließen oder
muß das Formular zur Aktualisierung erst geschlossen werden?

Stehen also die einzelnen Register untereinander in direkter Beziehung?

Die Preise für Reparaturarbeiten und Dienstleistungen sind in der angefügten DB EB 1.mdb in der Tabelle -Preise Dienstleistungen-hinterlegt.

Auch eine Tabelle mit Reifenschäden ist hinterlegt.
Dann habe ich noch eine Datei - Fuhrpark.xls(gepackt)- angehangen
Dort sind 167 Fahrzeuge mit Kennzeichen, Kostenstelle, SZM oder Auflieger hinterlegt.

In der DB gibt es ein Formular - Präsentation 2.
So ähnlich hatte ich mir das Eingabeformular für den Endnutzer gedacht.
Dort fehlen allerdings noch die berechneten Laufleistungen der einzelnen Reifen.
Und wichtiger noch ,es fehlen in dieser Datenbank die sinnvollen Aufteilungen und Beziehungen.

Ich habe auch noch eine zweite Datenbank - 16 07 07.mdb - angefügt.
Dort sind auch mehrere Tabellen mit Hintergrundinformationen vorhanden.
Dort kann ich allerdings mit dem Aufbau nicht solch ein Formular wie die gewünschte Präsentation 2 von der eb 1.mdb erreichen.

Dafür sind dort schon Preise und Formulare zur Berechnung ( 9 - Eingabeformular1) eingefügt.

Vielleicht bekommst du ja von den beiden DB eine ungefähre Vorstellung, was ich gerne hätte.

Am Besten, wenn ich ganz unverschämt sein darf - die Präsentation 2 aus der EB1.mdb mit dem Formular aus der 16 07 07.mdb und deine neue DB in einer vereinigt.

Das wäre cool - widerspricht sich aber wahrscheinlich durch völlig unterschiedlichen Aufbau der 3 Datenbanken.

Aber sieh meine 2 Datenbanken als Anregung für meine grafischen Vorstellungen.

Aber zurück zu deiner DB.

Wäre es möglich, an Stelle der Auftrags-ID dieVorgangs-Nr als Primärfeld zu übernehmen.

Außerdem wäre vielleicht das Kennzeichen als Primärschlüssel anstelle von Fahrzeug-ID möglich?

Im frm_auftraege kann ich nur den oberen Kopf ausfüllen.
Wenn ich ein noch nicht gelistetes Kennzeichen eingeben will, kommt eine Fehlermeldung.

Das Fahrzeug muß ich erst über die tbl_fahrzeuge anlegen.
Für mich ok - für den Endnutzer zu schwer.
Vielleicht einen Befehlsbutton einbinden zum Öffnen des Formulars zum Anlegen des KFZ,wenn es noch nicht gelistet ist.
Es wird immer neue Fahrzeuge geben - Zukauf usw., die in der xls Fuhrpark nicht enthalten sind - deshalb die Möglichkeit für den Eingebenden, dort direkt aus diesem Formular heraus eines anzulegen.

Im Register -Räder können die mm-Angaben zu den Positionen 1-8 eingegeben werden.

War die darunter liegende Tabelle für die Eingabe der restlichen Informationen gedacht?

Kann man es eigentlich so einrichten, das man bei dem Auswahlfeld -Profil- sowohl eines der gelisteten auswählen kann, als auch ein noch nicht gelistetes eingeben kann und das neue implementiert sich dann automatisch in die zu Grunde liegende Tabelle?

Diese Funktion zur Aktualisierung der Daten in den Grundtabellen wäre an vielen Stellen von Vorteil.

Im Register Sonstiges könnte man noch die Felder Gewaltschaden und Panne als ja/nein Optionsfeld definieren.

Ist bei deinem Aufbau der DB eine in etwa ähnliches Formular wie das Formular Präsentation 2 möglich?

Wenn ja, könnte man dort irgendwie die Laufleistung der einzelnen Reifen noch ausrechnen lassen.

Das Registersteuer-Element ist eine echt coole Angelegenheit.

Habe mich sehr über deine DB gefreut.

Vielleicht können wir sie zusammen noch weiter entwickeln.

Allerdings muß ich dabei sagen, das sich meine Kenntnisse von Access lediglich auf die Bedienung des Programmes beschränken.
VBA-Programmierung übersteigt meine Kenntnisse.
Ich mußte bisher so auskommen, habe es bisher auch immer hingekriegt - bis auf dieses Projekt.

Aber vielleicht klappt es ja mit deiner Hilfe.

Entschuldige meinen riesigen Beitrag - aber die DB ist so komplex - da kann man nicht nur mit 2 Zeilen alles abdecken.

Freue mich auf deine Rückantwort

mlceagle

 

Tja, ich habe es fast befürchtet, dass ich dir das Nachfolgende schreiben muss ...

1. Dieses Forum, bzw. diejenigen, die hier mehr oder weniger regelmäßig Fragen beantworten und/oder versuchen, Probleme zu lösen, verstehen sich nicht als Ersteller kompletter (noch dazu kostenloser) DBs; schon gar nicht, wenn die DB offensichtlich nicht privat, sondern von einem Unternehmen eingesetzt wird. Wenn ein Unternehmen eine DB benötigt, sollte es eine bei einem Entwickler einkaufen.

2. Ich erlebe es immer wieder, dass Mitarbeiter eines Unternehmens aus mehr oder weniger Eigeninitiative im Rahmen ihrer Arbeitszeit (teilweise auch in ihrer Freizeit) DBs für das Unternehmen entwickeln. Mir scheint das auch in deinem Falle so zu sein.

Ich bin mir aber nicht sicher, ob du dir dabei der Verantwortung voll und ganz bewusst bist, die du damit eingehst!? Momentan läuft vermutlich alles über Excel – zwar umständlich, aber es funktioniert und jeder kann „irgendwie“ mit Excel umgehen. Wenn nun eine DB eingesetzt wird, zentriert sich die Ein- und Ausgabe der Daten natürlich auf die DB und das heißt, die muss auf jeden Fall und immer funktionieren, sonst erleidet das Unternehmen einen Schaden.

Das wiederum heißt, dass du, als Entwickler der DB, zum einen in der Lage sein musst, auftretende Probleme zu beheben und zum anderen, zusätzliche Wünsche nach Veränderung und Erweiterung zu erfüllen. Wenn du das kannst, ist das ja noch o.k., wenn du aber zukünftig deinem Betrieb eine DB anbietest, die im Wesentlichen von mir oder irgendwelchen anderen Leuten stammt und deren inneren Aufbau du nicht verstehst, dann ist das ganz klar ein Höllenritt!!! Denn immer, wenn was an der DB repariert, erweitert oder verändert werden soll, wird dir das Herz bis zum Halse schlagen, weil du dann ganz schnell jemanden finden musst, der es für dich tut, weil du es ja nicht selbst kannst. Schlimmstenfalls könnte das sogar deine berufliche Position gefährden, da Kollegen und insbesondere Vorgesetzte keinen Spaß verstehen, wenn sich herausstellt, dass du nicht die Erwartungen erfüllen kannst, die du mit der (angeblich eigenen) Erstellung der DB geweckt hast.

3. Aus den genannten Gründen ist es für mich jetzt so eine Gewissensfrage, ob und wie weit ich dir noch helfen soll. Bitte verstehe das nicht als „Faulheit“ oder „Gemeinheit“ meinerseits, sondern genau das Gegenteil ist der Fall.

Es kommt sehr häufig vor, dass selbst Leute, die schon ein gewisses Maß an Erfahrung beim Erstellen von DBs haben, bei der Strukturierung Probleme kriegen und um Hilfe bitten. Auch dein „Hilferuf“ fängt ja so an:
a) ich habe zwar schon einge DBs erstellt,
b) doch dieses Mal krieg ich die Daten nicht vernünftig aufgeteilt.
Bei dieser Aufteilung habe ich jetzt geholfen und weil es bei der vorhandenen Komplexität ungemein viel zu schreiben und zu erklären gegeben hätte, habe ich dir lieber eine entsprechende DB als Anschauungsmaterial gemacht.

Ziel war aber ausschließlich, dir eine – hoffentlich – sinnvolle Struktur zu bieten; es war ganz eindeutig nicht das Ziel, dir eine komplett fertige DB zu erstellen!!!
Wenn du nun sagen würdest, dass die Struktur an irgendeiner Stelle nicht stimmt oder nicht funktionell ist, würde ich natürlich versuchen, das noch umzustellen.

Aber ich halte es nicht für sinnvoll, dir jetzt noch – z. B. - eine Schaltfläche einzubauen, dass ein Nutzer das Formular Fahrzeuge aufrufen kann. Das wäre für mich nicht einmal eine Minute Arbeit, doch wenn dein Wissen nicht ausreicht, das selber einzubauen, dann lass bitte, bitte die Finger davon, deinem Betrieb eine DB anzubieten, die du nicht verstehst und die du dementsprechend nicht warten kannst (siehe Pkt. 2)!!!

Du stellst in deiner letzten Antwort eine ganze Reihe von Fragen, die mir genau zeigen, was du nicht verstehst und wo es noch hapert. Dieses Nichtwissen ist ja keine Schande, jeder von uns hat ganz klein angefangen, doch ich habe Angst, dass das in Bezug auf diese DB ganz bös enden könnte. Ginge es um eine DB für deine private Briefmarkensammlung, hätte ich überhaupt keine Probleme damit ... aber nicht bei so einer „Firmen-DB“.

Würde bei euch ein Laie eine Zugmaschine fahren dürfen, oder gar reparieren?? Offenbar bist du DB-mäßig noch nicht so weit, eine DB mit der sich hier schon andeutenden Komplexität zu händeln oder sogar (weiter) zu entwickeln – das ist überhaupt nichts Schlimmes. Aber es brächte sowohl dich als auch deinen Betrieb in ziemliche Nöte, wenn dann mal ein Problem auftritt.

Ich kann dich nur ganz, ganz dringend bitten: tu dir und den anderen das nicht an!!!

Aus all diesen Gründen werde ich zunächst mal eine Antwort von dir abwarten, doch so oder so wird es keinesfalls so laufen, dass ich oder jemand anderes hier aus dem Forum dir eine fertige DB entwickelt. Im Forum geht es immer nur darum, für eine ganz gezielte Frage eine Problemlösung anzubieten.

Auch ein gemeinsames „Learning by doing“ (wir entwickeln hier gemeinsam deine DB weiter) ist ganz einfach zu viel verlangt. Dafür gibt´s Kurse, Bücher, von mir aus Privatunterricht – aber das übersteigt die Möglichkeiten eines Forums wie diesem hier bei weitem und das wäre weder bei mir noch bei jedem anderen, der hier im Forum Hilfestellung gibt, schon aus rein zeitlichen Gründen realisierbar.

Du hast jetzt noch zwei DBs und eine Excel-Tabelle angehängt, zusammen mit meiner hätten wir also vier Objekte und daraus machen wir „mal eben“ „irgendwie“ eine einzige ... das ist dann doch des Guten zuviel.

Ich kann mir vorstellen, dass du jetzt geschockt, enttäuscht und vielleicht auch ärgerlich bist, doch ich hoffe, dass du beim nochmaligen drüber Nachdenken merkst, dass ich in erster Linie eine möglicherweise sehr folgenschwere Entscheidung (Einführung dieser DB in deinem Betrieb) problematisieren möchte.

Bernd

 

Hallo Bernd

Entschildige, wenn es so rübergekommen ist, als wollte ich jemand anderen eine fertige Datenbank entwickeln lassen und heimse dann die Loorbeeen ein.
Dem ist definitiv nicht so.

Wie du ja an den 2 Datenbanken, die ich angehangen habe, sehen kannst, habe ich mir selber gewaltige Gedanken und Mühe angetan, um voranzukommen.

Mein Problem war und ist eigentlich immer noch, daß ich nicht weiß, wie ich die Struktur für die maximal 8 Reifen pro Fahrzeug mit dem jeweiligen Ersatz einzelner Reifen mit den Laufleistungen und die Beziehungen hinbekomme.
Bei deinem Entwurf ist dies leider, soweit ich es erkennen konnte,noch nicht integriert.

Die DB wäre für mich und meine Kollegen als Arbeitserleicherung gedacht.

Ich habe früher schon mal eine für einen anderen Aufgabenbereich erstellt, welche auch sehr gut geklappt hat.
Auch dort musste mal öfter was geändert werden.
Aber irgendwann war der Punkt erreicht, wo Sachen integriert werden sollten, die beim Entwurf nicht vorgesehen waren und dann nicht mehr implementiert werden konnten.
Das konnte ich dann auch ruhigen Gewissens vertreten.

Auch bei dieser habe ich klargestellt, daß alles was nachher noch rein soll, zu spät ist.

Ich verstehe aber durchaus deine Bedenken, und habe mir die Entscheidung, sie trotzdem zu erstellen, nicht leicht gemacht.

Ich werde weiter versuchen, eine Struktur hineinzubekommen und vielleicht mit kleinen Häppchen mich wieder ans Forum wenden.

Für deine Bemühungen bedanke ich mich nochmals.
Die Idee mit dem Stuerregister habe ich auch direkt in meiner DB noch umgesetzt.

Du siehst - selbst ist der Mann.

Aber Hilfe bei einer Blockade ist nie schlecht.
Und die hast du mir gegeben - Danke

mlceagle

 

O. K. Mit deiner Antwort bezüglich der Problematik einer "Firmen-DB" kann ich leben.

Dann möchte ich aber noch zwei Sachen machen:
a) einige Antworten auf deine Fragen geben
b) die Sache mit der Struktur klären.

zu a) Antworten auf deine Fragen
Wäre es möglich, an Stelle der Auftrags-ID dieVorgangs-Nr als Primärfeld zu übernehmen.
Außerdem wäre vielleicht das Kennzeichen als Primärschlüssel anstelle von Fahrzeug-ID möglich?
Kein Problem

Kann man es eigentlich so einrichten, das man bei dem Auswahlfeld -Profil- sowohl eines der gelisteten auswählen kann, als auch ein noch nicht gelistetes eingeben kann und das neue implementiert sich dann automatisch in die zu Grunde liegende Tabelle?
Diese Funktion zur Aktualisierung der Daten in den Grundtabellen wäre an vielen Stellen von Vorteil.
Ja, das geht. Die verbreitetste Möglichkeit dürfte das Ereignis NotInList (Bei Nicht in Liste) sein. Das ist allerdings dann schon ein wenig VBA.
Schau dir dazu am besten zunächst mal die Erklärung bei Karl Donaubauer an:
www.donkarl.com
Dort FAQ 4.13
Wenn das zu schwierig ist, erstelle ich dir ein Beispiel (aber du sollst ja erstmal selber lernen) *Smilie

Ein paar andere Sachen kannst du selbst machen (Text-Felder in Ja/Nein-Felder umwandeln usw.).

Was die Schaltfläche für die Tabelle Fahrzeuge angeht - das war von mir auch so angedacht, dass man im Auftragsformular eine Schaltfläche zum Öffnen des Formulars Fahrzeuge hat. Und wie ich an deinen DBs sehe, kannst du das ja auch allein.

Was die Aktualisierung im Register-Steuerelement angeht, so muss man unterscheiden:
- eine Reihe von Feldern stammt ja aus der qryAuftraege und bei denen ist es vollkommen egal, ob sie im Register stehen oder sonstwo im Formular, die sind immer aktuell

- bei Berechnungen solcher Felder hast du es in deinen DBs (z. B. in DB 16.07. / 9 - Eingabeformular ...) so gemacht, dass du die Sachen auf Formularebene ausrechnest.
Das kann man grundsätzlich so machen, hat aber zwei Nachteile: zum einen ist es tendenziell langsamer (was bei kleineren DBs allerdings kaum bemerkbar ist), zum anderen musst du diese Berechnungen aber in anderen Formularen oder auch in Berichten bei Bedarf wieder vornehmen; darum ist es eigentlich sinnvoller, das schon auf der Ebene der Abfrage zu machen.
(Nebenbei: irgendwo sprichst du davon, dass noch nicht gewisse Berechnungen ausgeführt werden - das hatte ich ja auch geschrieben, dass du dazu noch die berechneten Felder in der entsprechenden Abfrage anlegen musst und danach natürlich diese Felder dann auch ins Formular einzufügen sind. Rein optisch kann das dann genauso aussehen, wie du das jetzt in deinen Formularen hast).

- wenn im Register ein Unterformular liegt (auch da ist es aber egal, ob das im Register oder an sonstiger Stelle im Hauptformular liegt), musst du in manchen Fällen die Daten aktualisieren. Das bedeutet aber nicht, dass man dafür das Formular schließen und öffnen muss - sowas geht auch per VBA. Da es da aber viele Möglichkeiten und Situationen gibt, kann man das nur in einer konkreten Situation auch konkret beantworten. Diese Fragestellung solltest du dir also für später aufheben, wenn das Formular schon weitgehend "steht".


zu b) Struktur
Kann gut sein, dass ich da an einer Stelle die Sache anders verstanden habe als du sie brauchst. Es geht um die ehemals 14 und jetzt noch 8 "Päckchen" mit den jeweils 5 Feldern von Pos - ReifenNeuNr.

Ich habe nach Studium deiner ersten Excel-Tabelle geglaubt, dass nicht immer alle Reifen untersucht werden, weil ja in vielen Feldern in der Excel-Tabelle nichts drin steht. Später hast du dann mal geschrieben, dass alle Reifen eingemessen werden und die mm in das Feld Pos eingetragen wird. Somit habe ich gedacht, dass zwar bei Pos immer für jeden Reifen was drinsteht aber bei den übrigen Feldern nur, wenn der Reifen repariert oder ausgetauscht wird. Also habe ich die 8 Pos-Felder in der tblAuftraege gelassen und dann zusätzlich die Tabelle Raeder gemacht, die die übrigen vier Felder enthält und als Endlostabelle später im Formular so oft aufgerufen wird, wie Bedarf ist. Wird also Rad Nr. 2 repariert/ausgetauscht und fallen deshalb in einigen der vier Felder dafür Einträge an, so kannst du das in der Tabelle (Unterformular) eintragen. Räder, die nicht repariert/ausgetauscht werden, produzieren auch keine Einträge und müssen daher nicht aufgeführt werden. So war mein Verständnis.

Ich zweifle jetzt aber daran, dass das so richtig ist und habe eher den Eindruck, dass immer alle Räder untersucht werden und somit mindestens in Pos und in Profil auch immer für alle Räder ein Eintrag fällig ist. Falls das so sein sollte, brauchen wir natürlich nicht die tblRaeder und die Detailtabelle und alle 8 "Päckchen" gehören komplett in die tblAuftraege. Dadurch wiederúm könntest du dann in Bezug auf die Reifen-Daten auch die Felder-Anordnung wie in deinem Layout-Formular verwenden!! *happy

Das müsstest du jetzt also mal mitteilen, ob meine erste Annahme richtig ist oder ob die neue Einschätzung zutrifft (oder sich die Sache noch anders darstellt).

Was ich aber gar nicht nachvollzeihen kann, ist dein folgender Satz:

Mein Problem war und ist eigentlich immer noch, daß ich nicht weiß, wie ich die Struktur für die maximal 8 Reifen pro Fahrzeug mit dem jeweiligen Ersatz einzelner Reifen mit den Laufleistungen und die Beziehungen hinbekomme.

Das müsstest du nochmal genauer erklären (und ich habe auch den Eindruck, dass von Laufleistungen etc. bisher noch gar nicht die Rede war, oder???)

Tja, ich denke, das ist mal erst genug Text (wir halten da bestimmt schon Rekorde für Riesen-Beiträge). Hast du denn den Eindruck, dass die Daten-Struktur (von der Sache mit den "Päckchen" mal abgesehen) so stimmt wie ich sie in meiner DB dargestellt habe oder ist da an anderer Stelle auch noch nachzubessern?

Bernd

 

Hallo

Vielen Dank für deine Rückantwort.

Eines möchte ich vorweg noch erwähnen, was ich in meinem letzten Beitrag vergessen habe, zu erwähnen.

Mein stärkster Beweggrund für die Erstellung dieser DB ist es, mich selber in Sachen Access weiterzubringen.
Im Privaten Bereich ist es allerdings sehr schwer, ein passendes Beispiel für eine komplexe DB zu bekommen.
Denn eine Auflistung der Video-Casetten oder Musik-CD-Sammlung ist nicht wirklich so herausfordernd.

Um so mehr stellt diese DB eine Herausforderung zumindest für mich dar,
der ich mich auf jeden Fall weiter stellen werde.

Um so mehr freut es mich, wenn ich zu einem Problemfall von Dir eine Nachschlage-Adresse bekomme- siehe - Diese Funktion zur Aktualisierung der Daten in den Grundtabellen wäre an vielen Stellen von Vorteil.
Ja, das geht. Die verbreitetste Möglichkeit dürfte das Ereignis NotInList (Bei Nicht in Liste) sein. Das ist allerdings dann schon ein wenig VBA.
Schau dir dazu am besten zunächst mal die Erklärung bei Karl Donaubauer an:
www.donkarl.com
Dort FAQ 4.13
Wenn das zu schwierig ist, erstelle ich dir ein Beispiel (aber du sollst ja erstmal selber lernen)


Werde mich dort auf jeden Fall umschauen und versuchen, dies umzusetzen.

Zu dem Punkt - Aktualisierung von Daten im Register-Steuerelement.

Diese Frage hatte ich gestellt, weil ich in meiner DB - Datenbank 16 07 07
im Formular 9 -Aufträge1 einen neuen Artikel im Unterformular Auftragsdetails mit Befehlsbuttom - neuen Artikel anlegen - in dem sich dann öffnenden Formular 4-Preise Artikel-DL zwar anlegen kann.

Aber mal kann ich dann den neu angelegten Artikel im Unterformular-Auftragsdetails - auswählen, beim nächsten mal auf einmal wieder nicht.
Ich kann mir aber nicht erklären, warum es einmal funktioniert und das nächste mal wieder nicht.

Seltsam. Vielleicht könntest du mal in der bereitgestellten DB 16 07 07 den Fall nachvollziehen und hast eine Erklärung parat?

Nächster Punkt:

Um die Endberechnungen für die noch nicht berechneten Felder mache ich mir keine Sorgen-werde Sie am Ende über Abfragen erstellen.

Zur Struktur:

Deine letzte Annahme ist korrekt.
Bei jedem Fahrzeugkontakt wird jeder Reifen mit Profiltiefe (einzutragen bei Pos1 bis Pos6, ab und zu bis Pos8) und Profil (einzutragen bei Profil - dann 1-6(8))erfasst.
Eigentlich sollen in Zukunft auch immer die Reifennummern erfasst werden.

Somit bräuchte ich wirklich alle 8 Päckchen a 5 Spalten.

Zu dem Punkt:

Was ich aber gar nicht nachvollzeihen kann, ist dein folgender Satz:

Mein Problem war und ist eigentlich immer noch, daß ich nicht weiß, wie ich die Struktur für die maximal 8 Reifen pro Fahrzeug mit dem jeweiligen Ersatz einzelner Reifen mit den Laufleistungen und die Beziehungen hinbekomme.

Das müsstest du nochmal genauer erklären (und ich habe auch den Eindruck, dass von Laufleistungen etc. bisher noch gar nicht die Rede war, oder???)



Erstmalig habe ich in meinem ersten Beitrag vom 14 07 07 -Zeile 6-erwähnt,
das die Laufleistung der einzelnen Reifen am Ende irgendwie errechnet werden müssen.

Und mein Problem von Anfang an war - und deshalb auch meine Nachfrage nach einer DB-Struktur - , diese 8 Päckchen in der Struktur der DB richtig einzubinden mit entsprechenden Beziehungen.
(meine Annahme war ja 14 - du hast aber mit maximal 8 recht)

Der Rest der DB von Dir scheint alles richtig darzustellen, soweit ich es mit Probeeingabe einiger Datensätze nachvollziehen konnte.

Die Feinheiten wie Nachschlagetabellen usw kann ich ja, und habe ich teilweise schon, später durchführen.

Ich habe sicherlich schon wieder den Rekord für Riesenbeiträge gebrochen.
Tschuldigung - hihi

Auf jeden Fall nochmals Danke

mlceagle

 

Hallo -
noch zur Ergänzung zu meinem letzten Beitrag .

Habe deinen Tip

Schau dir dazu am besten zunächst mal die Erklärung bei Karl Donaubauer an:
www.donkarl.com
Dort FAQ 4.13

umgesetzt.

Habe dabei auf jeden Fall gelernt, das man formulare und felder auf keinen Fall mit Bindestrichen oder Leerschritten versehen sollte, gibt nur Probleme beim VBA.
Habe es aber trotzdem hinbekommen nach umbenennung des betreffenden Formulars und des betreffenden Feldes und der dazugehörigen verweise.

Funktioniert alles wunderbar.

Allerdings habe ich es an der selben Stelle ausprobiert, die ich in meinem vorigen Beitrag beschrieben habe - (mal klappt es - mal nicht.)

( Artikel neu anlegen).

Brauche jetzt auf jeden Fall keinen zusätzlichen Buttom mehr,um das Eingabeformular zu öffnen und einen neuen Datensatz zu eröffnen, um einen neuen Artikel anzulegen.

Wenn jetzt das mit der Speicherung des Artikels auch ohne Schließen und erneutes Öffnen des Hauptformulars klappen würde, wäre ich superglücklich.

Dies kann ich nämlich an mehreren Stellen dann benutzen.

Super Tipp trotzdem.

Danke

mlceagle

 

Zum Thema Access-Tipps
Da gibt es ungemein viele Seiten im Netz, doch sicher die berühmteste deutschprachige ist die genannte von Karl Donaubauer.

Weiterhin findest du sehr viele Anregungen (inkl. Beispielen/Downloads) u.a. bei

DBWiki
http://www.access-home.de
http://www.access-im-unternehmen.de/index1.php
Kulpa-Online - Manuela und Stefan Kulpa

aber auch auf den "Partnerseiten" des Forums:

Forum für Microsoft Office und Windows - kostenlos.
http://www.access-paradies.de/downlo..._beispiele.php

Wie gesagt, nur eine kleine Auswahl unzähliger Seiten.

Thema Struktur / Laufleistung etc.
Ja, das Wort Laufleistung ist im ersten Beitrag erwähnt, doch ich verstehe nicht, was du daran als Problem siehst. Wäre das nicht einfach - pro Päckchen - ein Feld mehr, in das man pro Reifen die km-Zahl(?) einträgt??? Da stecke ich zu wenig in der Thematik (oder bin zu begriffsstutzig *biggrin.gif* ), um dort ein Problem zu sehen. Also bitte ggf. mehr Input.

Wie geht´s weiter?
Bezüglich deiner DB wäre mein Vorschlag, dass du zunächst mal das Aktualisierungsproblem zurückstellst und versuchst, die DB ansonsten so zusammenzubauen, wie du sie brauchst.

Von der Tendenz her:
- auf der Tabellen- und teilweise Abfrageebene eher meine Struktur (natürlich mit Ausnahme der "Päckchen" - die kommen alle in die tbl_Auftraege)
- die Formulare gemäß deinen Vorstellungen

Im Grunde benötigst du eigentlich für viele Sachen nicht mehr die Einzelformulare, sondern könntest das Register-Steuerelement ausgiebig nutzen. Manchmal möchte man aber trotzdem lieber einige Einzelformulare haben. Das kannst du ja halten, wie du willst.

Wenn du dann damit fertig bist, stellst du diese DB wieder ins Forum und listest auf, wo es noch hakt (u.a. Aktualisierung, zweckdienliches Suchfeld für die Fahrzeuge usw.). Dann können wir von dieser einheitlichen Plattform weitermachen.

Einzig, wenn es mit Laufleistung und Co. noch Klärungsbedarf gibt, sollte das natürlich vorher besprochen werden, weil sich das evtl. auf die Struktur auswirkt.

Bernd

 

Hallo Bernd

Danke für die Links
Werde mich dort mal umsehen.

Zu den Laufleistungen:

Das Feld Laufleistungen müsste ein sich selbst berechnendes Feld sein.
Keines wo ich die Laufleistung händisch eintrage.

Und diese Selbstberechnung könnte meiner Meinung nach etwas schwierig sein, da in dem Feld verschiedene Ausgangssituationen berücksichtigt werden müssten.

A) KM-STand aktuelle Einmessung minus KM-Stand, wann der betreffende Reifen das letzte Mal erneuert wurde. (Kann unter Umständen mehrere Datensätze vorher gewesen sein)

B) KM-Stand jetzige Einmessung bis 0 km, wenn der Reifen vorher noch nie erneuert wurde, bzw. die Erneuerung nicht erfasst wurde.

Vielleicht mache ich es ja komplizierter als es ist.

Kannst du meinen Denk-knoten auflösen?

Werde jetzt auf jeden Fall versuchen, eine neue DB zu erstellen mit deiner Grundaufteilung und meinen Formularen.

In Punkto berechnetes Feld für die Laufleistung höre ich ja vielleicht von Dir.

Bis jetzt schon mal vielen Dank

mlceagle