Sehr viele Felder addieren

[//project2]

Hallo,

ich habe eine Tabelle mit einem Feld für Autowert, 2 bis 3 weitere Felder für andere Daten und dann nochmal 115 Felder für Zahlen. Die sind benannt nach G1, G2, G3 usw.

Wie kann ich diese am schnellsten zusammenrechnen ohne G1+G2 usw., da dieses in einem Bericht innerhalb eines Textfeldes zu lang ist und ich das auf mehrere Textfelder (versteckt) aufteilen muss, um diese dann zusammen zu rechnen.

Oder ist meine Denkweise für die Tabelle falsch?

Das zugehörige Formular für die Eingabe enthält auch 115 Eingabefelder für die Zahlen.


Danke euch

[MzKlMu]

Hallo,

am schnellsten zusammenrechnen ohne G1+G2 usw.,

Gar nicht. Die Tabelle ist falsch. Du brauchst eine extra Tabelle mit einem Fremdschlüssel zur jetzigen Tabelle. In dieser Tabelle werden die Werte als Datensätze erfasst (als 115 Datensätze mit einem Feld "G". Dann kannst Du in einem weiteren Fels einfach summieren.

Code [Auswählen] Erweitern

=Summe(G)Auch das Formular ist dann falsch, zur Erfassung derte wird ein Unterformular (im jetzigen Formaular) angelegt zur Erfassung der Werte.

Was sind denn das für 115 Werte ?

Zeige mal ein Bild des Beziehungsfensters.

[//project2]

Sie dürfen in diesem Board keine Dateianhänge sehen.

okay, ich habe es jetzt also so gemacht: die WB1 bis WB7 und Reserve enthalten dann jeweils die Zahlen und sind jetzt auch im Unterformular eintragbar. klappt auch alles, jedoch soll der Nutzer bei Eingabe der Werte von oben nach unten wandern, sprich zuerst WB1 füllen, dann WB2 usw.

Beim öffnen wird jedoch auch nur eine Zeile angezeigt, somit ist auch kein navigieren nach unten per Pfeiltasten möglich. Kann man die Anzahl der Datensätze im Unterformular schon vorher festlegen und auch so anzeigen lassen? und eventuell sogar bei drücken von Enter nach unten statt nach rechts zu springen?

[Knobbi38]

Hallo,

Felder mit Nummern als Aufzählung in einem Datensatz deuten auf ein nicht normalisiertes Datenmodell hin. Normalisiere deine Tabellen, so wie Klaus das schon empfohlen hat, bevor du mit dem Designen von Formularen anfängst - so etwas ist Excel denke und hat mit Datenbanken dann nichts zu tun.

Man kann auch in Access so ein Erfassungsformular gestalten. Da das aber nichts mehr direkt mit einer üblichen Vorgehensweise zu tun hat, kann nicht auf eine automatische Unterstützung durch Access zurückgegriffen werden, sondern muß das von Hand programmieren.

Gruß Knobbi38

[MzKlMu]

Hallo,
wie Ulrich auch sagte, das Datenmodell passt nicht.
Was Du da jetzt gemacht hast, entspricht auch nicht meinem Vorschlag.
Hier fehlt auch noch mindestens eine Tabelle.

Du solltest auch mal erklären, was das für 115 Werte sind.
Und wie bereits erbeten, das Beziehungfenster hier mal zeigen. Ich befürchte aber, es gibt nur diese eine Tabelle und somit auch keine Beziehungen.

[markusxy]

Kann man die Anzahl der Datensätze im Unterformular schon vorher festlegen und auch so anzeigen lassen? und eventuell sogar bei drücken von Enter nach unten statt nach rechts zu springen?

Vielleicht erklärst du mal die Hintergründe.
Via VBA kann man das gewünschte Verhalten grundsätzlich erreichen.
Man sollte aber grundsätzlich vor dem Anlegen/Ändern der Strukturen, den ganzen Workflow durchdenken.
Idealerweise hält man sich an die Grundsätze der Normalisierung so wie schon angesprochen, dann dann ist man bei künftigen Anforderungen auf der sicheren Seite - und versucht nur das User Interface entsprechend anzupassen.

[//project2]

Wie ihr schon vermutet hattet, gibt es bei dieser Tabelle keine Beziehung, bzw. nur eine und die ist für den Lagerort.

Die 115 Werte sind Gewichtangaben aus Wiegungen und sind pro Lieferung zu füllen, sprich ein Datensatz mit 115 Werten.

Das Formular sollte halt für den Bediener so einfach wie möglich sein und über die eine Tabelle konnte ich erreichen, 115 Eingabefelder in das Formular zu setzen, die per Tab immer um eins weiterspringen.

Die Felder sind dann in 6 Wechselbrücken (Gruppen) sortiert, deswegen auch in meinem zweiten Versuch oben die Felder WB1, WB2, usw.

Theoretisch kann ich auch mit nur einem Feld für alle Gewichte in der Tabelle auskommen, müsste dann aber auf dem Formular wiederum in WB1 bis WB6 gruppieren und als Formular eine feste Anzahl von Daten (115) erreichen, ohne dass man die Tabelle weiter füllen kann.

[MzKlMu]

Hallo,

Die Felder sind dann in 6 Wechselbrücken (Gruppen) sortiert,

Wie sind die aufgeteilt ?
115/6 geht ja nicht auf.

Man könnte überlegen, die Felder ungebunden anzulegen und dann per Button die Daten mit einer Schleife über die Felder in die normalisierte Tabelle einzutragen.

[Bitsqueezer]

Hallo,

in einem Lager hat man Lagerorte. Ein Lagerort ist i.d.R. frei in dem, was man dort lagert, also z.B. nicht an ein Produkt gebunden. Heute dieses Produkt, morgen jenes. Man kann das natürlich auch so handhaben, daß es immer das gleiche Produkt an immer dem gleichen Lagerort ist.

Der Begriff "Wechselbrücken" zeigt dann, worum es eigentlich geht. Ich mußte das auch erst mal nachschlagen, kannte den Begriff noch nicht.
https://www.timocom.de/lexicon/transportlexikon/wechselbruecke

Es geht also quasi um einen auswechselbaren Laderaum für LKWs. Daher ist dann natürlich Mischware zu erwarten und das Gesamtgewicht ist für die Beladung natürlich auch von Bedeutung. Da diese auch als "mobiles Lager" verwendet werden, gibt es u.U. gar kein anderes Lager, aus dem diese beladen werden (aber das müßtest Du dann schon näher erläutern).

Ich würde entsprechend hier als Beispiel so vorgehen:
WB1 bis WB7 sind physikalische "Lagerbehälter". Hier könnte sich jederzeit etwas ändern, z.B. wird ein WB8 hinzugekauft oder ein existierender entfernt, verändert, was auch immer.

Entsprechend braucht es eine Tabelle "tblWechselbrücken", die die einzelnen Container beschreibt. D.h., je Zeile eine Wechselbrücke. Hier kann enthalten sein: Name, Hersteller, LetzteWartung, Länge, Breite, Höhe, ZulässigesGesamtgewicht (also der Ladung).
Diese Tabelle dient als Bezug, als Lookup-Tabelle für andere Tabellen, um diese und andere Informationen über die Wechselbrücke selbst zu speichern und nicht irgendwo wiederholen zu müssen.

Da die WBs mobil sind, würde sich sicherlich eine Tabelle anbieten, in der man den aktuellen Status hinterlegt, also sowas wie, mit welchem LKW, welcher Spedition, unterwegs oder nicht, uvm.

Die Wiegungen pro Lieferung wären vermutlich davon abhgängig, ob eine Lieferung in einem oder mehreren WBs geliefert werden kann. Entsprechend wäre es eine Tabelle "tblLieferungen", in der man Daten hinterlegt wie Lieferdatum, Spedition, Liefernummer.
In einer weiteren Tabelle wären es dann die Wiegungen, mit Daten wie LKW, ID des WBs, Gewicht.

Ein Formular sähe dann ähnlich aus wie der Screenshot oben mit Hauptformular mit den Lieferungsdaten und einem Unterformular, in dem es ein Feld für die Auswahl der WB-ID gibt und ein Feld für Gewicht, sowie weiteren möglichen Daten zur Wiegung.
Da die Eingabe dann zeilenweise erfolgt, kann beliebig gemischt jede WB ausgewählt werden oder immer erst eine WB und dann die nächste. Zusätzlich kann ein zweites Unterformular z.B. neben dem ersten alle zu einer Lieferung gehörenden WBs und ihrer erfassten Gewichtssummen anzeigen.

Zusätzlich kann man die gleiche Wiegungstabelle über ein Feld "Eingang" (Ja/Nein) verwenden, um auch Beladungen für Ausgänge zu speichern. Die Summenliste kann dann auch die Gewichte gegen das zulässige Gesamtgewicht testen.

Wenn man mehr benötigt, z.B. bestimmte Produkte auf bestimmte WBs oder Abgleich mit einem stationären Lager usw., braucht man dann noch einige Tabellen mehr.

Also Du siehst, daß man schon genau beschreiben muß, was die Anforderungen sind, dann kann man Dir auch aufzeigen, was eine sinnvolle Lösung sein kann. Das dargestellte Unterformular mit mehreren WB-Spalten ist auf jeden Fall keine gute Idee. Daten in Datenbanken sind zeilenweise orientiert, Spalten mit gleichartigen Informationen nebeneinander, das gibt es in guten Datenbanken i.d.R. nicht, da es sich dann um eine Pivottabelle handelt.

Gruß

Christian

[//project2]

So kompliziert muss es gar nicht sein.
Die Wechselbrücken enthalten Paletten, jede davon ist eines der 115 Werte.

Die Lieferungen von verschiedenen Niederlassungen (hier in der Tabelle als Lager geführt) (jede bis zu 6 Wechselbrücken) sind jeweils ein Datensatz.

Die Brücken werden abgeladen, die Paletten gewogen (Schrott, alles durcheinander).
Befüllt werden die nicht mehr, nur für die Buchhaltung müssen diese in der Datenbank festgehalten werden.

Der Schrott wird später sortiert, ist aber in dem Fall jetzt auch egal. Wichtig ist nur, dass dann aus diesen Daten ein e Auswertung erfolgen kann nach Monaten, Jahren, Lager usw

[Bitsqueezer]

Hallo,

ja, das sind schon wichtige Hintergrundinformationen.

Mehrere Niederlassungen, da beginnt es mit einer Tabelle der Niederlassungen, die wenigstens die Namen enthält, ggf. weitere wie Adresse usw.

Eine Tabelle Wechselbrücken, die, wie oben gezeigt, die Basisinformationen enthält und z.B. eine Niederlassungs-ID, damit zugeordnet ist, welche davon welcher Niederlassung gehört (sofern das nicht völlig egal ist, weil alle etwa dem gesamten Unternehmen gehören und die Standorte der WBs beliebig sind und keiner Lokation gehören).

Nur Entladung von Schrott ist schon mal ein wichtiger Hinweis - es geht also um keinerlei Produkte, die irgendwo eingelagert werden müssen, eher dann später um Materialiensortierung.

Weiterhin gäbe es dann eine Liefertabelle und eine Tabelle mit Gewichten, wie oben beschrieben, das Feld für Eingang entfällt dann. Lieferungen können auf mehrere WBs aufgeteilt werden, jede Lieferung kann also dann aus mehreren WBs bestehen (oder natürlich auch nur einer).

Vorteil der Verwaltung über getrennte Tabellen: Wenn mal ein WB verschrottet wird, kann man ihn in der WB-Tabelle mit einem Verschrottungsdatum kennzeichnen und er wird dann in neuen Lieferungen nicht mehr zur Auswahl angeboten. Wenn man einen neuen kauft, erfaßt man den in der WB-Tabelle und schon kann er sofort benutzt werden. In Deinem jetzigen Modell wäre das ohne aufwendige Umbauarbeiten in den Formularen nicht machbar.

Mit dem gezeigten Modell kannst Du auch viele Zusatzinformationen aus den Daten entnehmen, z.B. wie oft welcher WB gebraucht wurde, wann der nächste TÜV für einen WB fällig ist, mit wieviel Gewicht welcher WB im Durchschnitt beladen wird uvm.

Mit einer gut aufgebauten Datenbank kann man eine Menge machen, was erst einmal nicht sofort zu erkennen ist. Ein schlechtes Datenmodell bewirkt dagegen, daß man an allen Ecken Probleme bekommt - wie Du ja selbst in Deinem Eingangsposting bemerkt hast, nämlich 115 Gewichte einzeln addieren zu müssen und viele weitere Probleme, die Du jetzt noch gar nicht siehst.

Je früher das Datenmodell stimmt, desto besser. Die Formulare bestimmt man erst danach und wie sie am besten zu strukturieren sind. Je weniger man gegen die Access-Automatismen arbeitet, desto einfacher ist es, bis hin zu völlig codefrei.

Gruß

Christian

[//project2]

Okay ich werde nochmal sehen, dass ich es anders mache.

Übrigens werden die WB nicht erfasst, weder mit TÜV, noch mit Austausch.

Die Kennzeichnung im Formular ist auch nur wie viel Material aus welcher WB entnommen wurde. Die WB sind auch nicht speziell gekennzeichnet und müssen auch nicht mit in die Datenbank. Erfasst wird nur, welche Lieferung von woher kommt. Und das sind ja dann pro Lieferung immer bis zu 6 WB.

Aber wie gesagt ich schau nochmal. Vielen Dank erstmal bis hierhin.