Moinm
sehr wohl, Du verstehst es nicht…
Nein, Du verstehst die glaßklare Fragestellung ganz und gar nicht! Du bist am Anfang (getriggert durch meine umständliche Formulierung) auf den falschen Dampfer gekommen, und ich schaffs nicht, Dich davon herunter zu bekommen!
Nur Fremdschlüssel?? Das fällt mir spontan die Menge, der
Einzelpreis, die Mehrwertsteuer, Rabatt und dergleichen ein,
die in diese Tabelle gehören… (Wie auch schon letzthin
erwähnt)
Brauche ich in dieser Anwendung NICHT!
WAS für ein Betrag ist das und wie wird der berechnet??
Die Summe!
Und nur da, wo solche Rechnergebnisse wirklich gebraucht
werden, können sie aktuell durchgeführt werden.
Stimmt! Ich hatte nur schon komische Resultate. Derzeit geht es via Abfrage sehr gut!
Daraus resultierend habe ich nun ein Formular mit einem
Unterformular als Tabelle.
Wie lautet die Datenherkunft des (Haupt-)Forms?
Tabelle: Bestellungen/Bestelldetails!
Wie lautet das Herkunftsobjekt des UFO-Steuerelementes?
Artikel In Bestellungen (Tabelle, die mit nur Fremdschlüsseln)
Tabellen als UFO einzubinden ist unsinnig. Benutz ein
Endlosform („frmBestellPositionen“) mit Datenherkunft auf die
Tabelle (hier „Artikeln in Bestellungen“) und zeige das in
einem UFO-Steuerelement an.
Warum ist das Unfug? macht jedes Rechnungsprogramm so und ist erheblich übersichtlich, meiner Ansicht nach! Macht auch die DB, die ich nicht erwähnen darf!
Setze die
Verknüpfungseigenschaften des UFO-Steuerelementes auf die
entspr. Schlüsselfelder.
??
Das habe ich nie gesagt und Du hast es missverstanden. Was
soll eine Artikelauswahl im Hauptform, das Bestellungen als
solche (d. h. ohne Positionen) anzeigt?
Wie ich bereits ausgeführt habe, könnte man somit das UFO „laden“: Aus dem Kombi-Feld einen Artikel auswählen und per Button hinzufügen!
Nix erzählst Du dazu, Du erzählst immer was anderes.
Das ist nicht richtig, was Du schreibst! Ich erzähle da immer (fast) das selbe!
Wo ist der Denkfehler?
Du denkst immer nur an die „ähnliche“ Nordwind-DB… statt auf
mein Vorschläge einzugehen und die DB, d. h. die Tabellen und
(später) die Formulare zu korrigieren.
Ich habe die Vorschläge so umgesetzt, wie ich sie verstanden habe. Wenn Du es so erklärst…
Mag ja sein, dass Du den Sinn nicht erkennst… . Und mit der
Anwendung hat das auch nichts zu tun.
Das heißt konkret? Hilft nicht weiter, und den Sinn erkennst eher Du leider nicht. Es klingt jetzt wie „Schwarzer Peter Schieben“, ist aber nicht so gedacht! Ich verlgeiche mit der Nordwind, weil die fast genau das beinhaltet, was ich brauche, nur leider brauche ich 95% der Features nicht. Nochmal:
Ich habe eine Item-Liste (Artikelliste, dazu gibt es eine Tabelle). Diese Items werden einem bestimmten anderen Item (ich habs hier Rechnung genannt) zugeteilt (Für diese „Über“-Items gibt es ebenso eine Tabelle, für die Zuteilung die Fremd-Schlüsseltabelle mit Positionsangaben). Ich möchte nun in der Formularansicht der Über-Items diesem Items zuteilen können (also Artikel in eine Rechnung stellen) und diese in der Reihenfolge sortieren. Das alles kann die Nordwind, bis auf das Sortieren. Mehr brauche ich aus der Nordwind nicht, daher der Vergleich. Nichts anderes erhält ich seit Thread-Start. Ich erwarte gar keine Patent-Lösungen oder konkret-Lösungen. Wenn es ein Tutorial (etc.) gibt: Her damit! Ich fuchse mich auch selbst da durch. Allerdings sind generelle Access-Seiten oder die MS-Hilfe viel zu unkonkret, da mir die Nomenklatur/Begrifflichkeiten fehlen.
Viele Grüße und Dank bis hier
Florian
Der Artikel (die ArtikelID, die mit dem Kombifeld ausgewählt
wird) gehört in die Positionstabelle („Artikeln in
Bestellungen“, wenn sie denn so heißt, was an sich schon
sträflich ist: Sonder- und Leerzeichen sowie reservierte
Wörter bei der Benamsung DRINGEND vermeiden ) und fertig ist
die Laube.
Wenn die Anzeige der vorhandenen Artikel in der Kombifeldliste
nach einer bestimmten Spalte sortiert werden soll, so ist das
im SQL-String (Abfrage) in der Datensatzherkunft des Kombis zu
erledigen… (Beispiel auch schon gezeigt).
Da beißt die Maus den Faden nicht ab. Wenn es in Deiner
Anwendung so nicht gehen sollte, dann wirf die Anwendung in
die Tonne… Die wird nie funktionieren.
So ähnlich ist es ja in der Nordwind-DB,
Lass diese Db einfach mal außen vor, Vergleiche damit bringen
nix.
Ich wiederhole mich… Die ganze (prinzipielle) Konstruktion
habe ich schon mehrmals erzählt.
Gruß
Franz, DF6GL
as hätte ich sauberer als Frage stellen sollen, dass
! Ich suche nur eine Lösung für die Handhabung des Nutzers im Formular, keine DB-Konzepte; wie gesagt: Es ist so in den Tabellen realisiert, wie Du vorgeschlagen hast.
