Office: (Office 2016) Inhalt von Textfeldern in eine ungebundene Tabelle einfügen?

Hallo Klaus.

Danke ja sowas ist schon für mich sehr gut.

Ich schaue mir sowas natürlich schon im kern an und sehe allein schon anhand der Beziehungen einen unterschied. wie strukturiert soetwas sein sollte.

Aber wenn ich zum Beispiel oben den Kunden Eintrage ändert sich an den Kundendaten in Textfeldern nicht.

Allgemein wäre hier meine Frage ob ich da an der stelle nicht lieber mein eigenes Filtermakro verwenden kann.

Denn die häufigst genutzten spalten sind hier
(Nach reihenfolge)
1. Telefonnummer
2. Nachname
3. Straße und Hausnummer.

Das hatte ich ja alles in meinem Filtermakro deklariert sodass man
1. +4923456789
2. Müller
3. Musterstraße 99
eingeben konnte und er das auch so ausgespuckt hat.

Klar du hast ja gesagt das ich sie abändern kann aber ich frage lieber noch aus sicherheit. *Smilie

 

Hallo,
das Beispiel dient nur der Anschauung, das muss auf Deine Verhältnisse angepasst werden.

Ist der Satz jetzt auf mein Beispiel bezogen ?

In meinem Beispiel wird im Formular oben über die Kundennummer gesucht, das kann genau so gut auch eine Telefonnummer sein.

 

So entschuldige konnte bis gestern Abend kein Internet nutzen aufgrund einer Störung von Unitymedia in meinem Gebiet -.-

Jedenfalls habe ich natürlich offline dann an der Datei gearbeitet.
Ja ich bin auch dabei das anzupassen alleine aufgrund der Struktur der Datenbank.

Aber kann ich mit dieser dann auch wirklich ohne Abfragen arbeiten?

Jedenfalls auch mit der Kundennummer, habe ich gesehen und ja doch da hast du recht. Darüber macht er das *Smilie

 

Hallo,

Wieso ohne Abfragen ?
Eine Datenbank braucht immer Abfragen.
Außerdem, sollte die Datenbasis eines Formulars immer eine Abfrage sein, schon alleine wegen definierter Sortierungen.

 

Okay gut *Smilie Ja weil in dem Beispiel jetzt keine Abfragen existieren, dachte ich ich frage lieber vorher *Smilie

Aber ich sollte dann am besten in dem Formular für die KundenSuche die Abfrage mit der Tabelle "Adressen" verwenden und für das Formular "Bestellungen" dann die Tabelle "Artikel" und dann später die Bestellung aus beiden zusammenfassen lassen oder?

Hatte es ja in der Vergangenheit versucht die Kunden noch mit in die Bestellung zu ziehen was ja unnötig viele Datensätze erzeugt hat *biggrin.gif*

-Nebenbei gefragt-
Wie mache ich das dann am besten das ich die Bestellung vom heutigen Datum allgemein anzeigen lasse anstatt die vom gesuchten Kunden? *Smilie Ich denke ich werde dann die Tabelle "Bestellungen" mit den nötigen Feldern versehen müssen und nachher dann die Ansicht abändern das er alle Bestellungen anzeigt die = CurrentDate.
Oder besteht die Möglichkeit das er anhand der KundenID dann bestimmte Kundeninformationen lädt?

 

Hallo,
das Formular bei Dir ist ähnlich aufzubauen wie in meinem Beispiel.
Im Hafo wird er Kunde angeziegt.
Im Hafo ist ein Ufo für die Bestellung. Die Bestellung braucht ein Fremdschlüsselfeld für die Piza. Im Ufo für die Bestellung ist wieder ein Ufo für die eigentliche Pizazusammenstellung.
Du brauchst also zunächst mal folgende Tabellen:

- Kunden
- Piza (alle Piza die es gibt als je Ein Datensatz)
- Bestellung (mit FS zum Kunden und FS zur Piza)
- Zutaten (alle Zutaten mit Preisen)
- Pizazusammenstellung (FS zur Bestellung, FS zur Zutat, Menge Preisfeld)

 

Oh Danke das ist schon gut.

Danke für diese Übersicht *Smilie

Ja die Tabellen habe ich schon und auch an sich Ordentlich wie im Beispiel. Unnötige Felder oder aufzählungen sind nicht vorhanden.

Aber was meinst du mit "FS"?
Hafo und Ufo kenne ich schon durchs anlesen.

Also die Pizzazusammenstellung ist bei mir aber anders.

Ich nenne dieses Ufo SpeisenSonderheiten
da diese ja nicht nur für Pizza gilt sondern auch für Döner, Pasta, asia.
Aber an sich ja kein Problem ist ja das selbe prinzip bzgl. Zutaten und Preise.

Aber ist auf jedenfall schonmal gut, ich baue das dann getreu dieser Richtlinie auf. Ich denke so ist es am besten mit den Zutaten zu arbeiten *Smilie

Wenn ich jetzt noch wüsste was du mit FS meinst hätte ich durch dich schon einen super wegweiser *biggrin.gif* Für mich würde das nun File System heissen.

Grus
Jannis

 

Hallo,
FS=Fremdschlüssel. Das sind die Felder die in meinem Beispiel ein _F hinten haben. Das ist die n-Seite der Beziehung. Die 1-Seite ist der PS (=Primärschlüssel). Das sind die Schlüsselfelder die das _F nicht enthalten.

Siehe Bild aus dem Beispiel.

 

Sehr gute Ansicht, danke dafür *Smilie

Also von "Bestellungen" eine FS zu "Speisen" und "Kunden"
Und von SpeisenSonderheiten bilde ich FS zur "Bestellung" und zu den Zutaten *Smilie

Aber wie soll ich die Tabelle in deinem Beispiel jetzt Pizazusammenstellung, bei mir SpeisenSonderheiten aufbauen? Also was wären hier nötige Felder, da bin ich mir noch unsicher.
Vorallem wenn man 2 Zutatenauf die Speise machen will.


Dann mache ich mich mal dran

 

Also ich habe die Tabelle nun aufgrund deiner Vorlage mal so eingerichtet.

Das sollte an sich so stimmer, wenn nicht bitte sagen *Smilie

 

Hallo,
die SpeisenMenge gehört in die Tabelle mit den Bestellungen.
GesamtPreis ist überflüssig, wird immer errechnet aber nicht gespeichert.

Können mit einer Bestellung mehrere unterschiedliche Speisen bestellt werden ?
Wenn ja, fehlt noch eine Tabelle.
BestellungSpeisen, mit einem FS zur Bestellung und einem FS zur Speise.

Zeige mal ein Bild des Beziehungsfensters.

 

So sehen meine Beziehungen aktuell aus. *redface.gif*

Und ja es soll nicht nur ein Produkt bei einer Bestellung möglich sein sondern auch mehrere Produkte. *Smilie

 

Hallo,
mir ist immer noch nicht kalr, wie jetzt Deine Speisen sind.
Hast Du eine Speisekarte in der alle Speisen mit ihren Grundsammenstellungen und ihrem Preis enthalten sind. Und die werden dann bestellt.
Dann gibt es dann noch Sonderheiten die zusätzlich zu einer Speise bestellt werden können, mit den entsprechenden Aufpreisen.
Ist das richtig?
Wenn ja, stimmt das Datenmodell noch nicht.

Wieso gibt es bei den Zutaten 3 Preise, PreisGroß, PreisKlein und Preis ?
Bezeiht das nicht eher auf die Speise, Piza groß, Piza klein, oder oder große Portion Sonderheit oder Kleine ?

Kläre das jetzt erst mal zweifelsfrei. Ich hatte noch nie einen Pizaladen, das muss man mir alles erklären. *grins

PS:
Wenn Du ein Beziehungsbild machst, dann bitte alle Tabellen so groß ziehen, dass man alle Felder einer Tabelle sieht, sonst macht das Bild keinen Sinn.

 

Okay, jetzt habe ich auch endlich mal wieder paar Tage für mich *biggrin.gif*

Also es gibt eine feste Speisekarte. Dort gibt es nicht nur Pizza, sondern auch Asia, Döner, Pasta, Schnitzel und Baguettes.

Manche Speisen gibt es in unterschiedlichen Größen.
Deswegen die unterschiedlichen Preise bei den Zutaten.
Wenn man bei einer Kleinen Pizza als Beispiel "extra Käse" bestellt kostet dieser bei einer kleinen 0,50€. Bestellt man diese Zutat allerdings bei einer großen Pizza, zahlt der Kunde 1,50€.

Die Zutaten sind allerdings nicht auf der Speiseliste gelistet.
Aber natürlich gibt es diese, kennt ja an sich jeder, bei einer Bestellung extra Zutaten zu bestellen.

''Dann gibt es dann noch Sonderheiten die zusätzlich zu einer Speise bestellt werden können, mit den entsprechenden Aufpreisen.
Ist das richtig?
Wenn ja, stimmt das Datenmodell noch nicht.''

Um es also kurz zu sagen, ja.

Zu dem Bild.
Naja stimmt, man sollte schon alle Felder sehen können. Aber ganz Sinnfrei ist es ja auch nicht, immerhin kann man so schonmal sehen wie die Beziehungen gesetzt sind.

 

Hallo,
nein, sinnfrei war das Bild nicht. Aber um beurteilen zu können, ob es richtig ist muss man alle Felder sehen. Also lade das Bild bitte noch hoch.