Office: Feldinhalte aus Formular in unterformular kopieren

Hallo, ich habe ein
Formular1 in dem ich über Felder Werte auch einer Tabelle über eine Abfrage in Formular2 mit Unterformular schreibe (Auswahl Material und Materialdicke)

Im Formular2 sind diese Werte mit Preis usw.. im "Hauptformular" sichtbar und läuft auch gut.
Nun möchte ich einige dieser Werte / Felder in das Unterformular "kopieren" um der Kalkulation - die im Unterformular durchgeführt wird - mit dem zuvor ausgewählten Material "statisch" in der Tabelle die wirderum dem Unterformular zugeordnet ist zu speichern.

Leider schaffe ich es nicht den Inhalt der Felder über einen Button oder "Aktion" wegzuschreiben!

Wie kann ich so etwas einfach lösen - bin nicht der VisualBaisic Crack..*wink.gif*

:)

 

Hallo,
anscheinend bin ich nicht die einzige die deine Frage verwirrt zurücklässt *wink.gif* .
Daten befinden sich in Tabellen, Formulare sind zum Bearbeiten dieser Daten. Das Konzept, bereits vorhandene Daten zur Berechnung "in ein Unterformular zu schreiben" hört sich sehr nach Excel-Denke an - das funktioniert in einer Datenbank/Access anders.
Du musst im Prinzip dem Unterformular beispielsweise per Abfrage die benötigten Daten in der Datenherkunft des Ufo zur Verfügung stellen - oder die Berechnung über eine Funktion oder Abfrage machen und dann das Ergebnis in die Datenherkunft des Ufo übertragen.
Um dir also weiterhelfen zu können, müsste man etwas mehr über die Struktur deiner Tabelle(n) und die konkreten Berechnungen erfahren, dann findet sich sicher auch ein Lösungsweg.
maike

 

hab ich mir schon gedacht das das verwirrend klingt:
Zum Aufbau:
es gibt eine Tabelle mit Materialinformationen und vor allem aktuellen Einkaufspreisen. Die Preise sind starken Schwankungen unterlegen.
Somit möchte ich in der Tabelle immer aktuelle Einkaufspreise pflegen.
Dann gibt es ein Formular über das ich Material auswähle und dann über eine Abfrage in ein Formular mit Ufo schreibe. Basis des Hauptformulars ist die Abfrage um an die aktuellen Preise zu kommen.
Unterformular ist meine Kalkulation (nach Excel Vorbild)- brechnete Felder mit einer Tabelle Einzelteile im Hintergrund um die Artikel dauerhaft zu speichern.
Um die aktuellen Preise dem Artikel bei der ersten Kalkulation zuzuordnen muss ich diese FIX in der Tabelle Einzelteile wegspeichern- um aber immer die Kontrolle zu haben was wäre eigentlich der aktuelle Materialpreis brauche ich auch die aktuellen Preise im Hauptformular.
So könnte ich immer sehen passt der Preis des Bauteils noch oder muss ich hier neu verhandeln.

hoffe, dass es etwas licht ins Dunkel bringt.

 

Ok, ich hoffe, ich habe es jetzt einigermaßen verstanden.
Du hast eine Tabelle mit Material/Preis jetzt und eine mit Einzelteilen, in der der Preis zum Zeitpunkt der Kalkulation festgehalten ist.
Diesen Preis möchtest du gegebenenfalls ändern bzw. neu eintragen.

Da könnte ich mir vorstellen, über einen Doppelklick auf's Formularfeld im Hauptform den Wert zu übertragen, etwa so:
Code:

Diesen Befehl als Ereignisprozedur im Ereignis Bei Doppelklicken des Feldes im Hfo anlegen, die Feldnamen an deine anpassen.

Nachteil ist natürlich: einmal übertragen ist der alte Wert futsch.
Eine Preishistorie für die Materialien wäre da ein Ansatz, mit einem Feld PreisGueltigAb hättest du alle auch nachträglich im Zugriff.

maike

 

Servus,

Ich würde empfehlen, sogar eine Kalkulationshistorie zu erstellen und darin
eine Preishistorie für die Materialien redundant zu hinterlegen.
Es kann sehr komplex werden, über rel. Beziehungen das alles sauber zu organisieren.

 

Danke für die Info,
das werde ich am Wochenende mal versuchen einzubauen.
Geht sicher auch über Button und mit Doppelklick für mehrere Felder!?

Die Preise sind sicher interessant als Historie in ein Memo - Textfeld zur Info einzubauen die dann hintereinander ggf. mit Zeilenumbruch und Datum eingefügt werden.
Hättest Du da eine Programmzeile um diese Infos wegzuschreiben.
Sonst sind wie Du schon richtig eingeworfen hast die alten Werte futsch!

Gruß
Volker

 

Geht auch für mehr Felder, einfach nach demselben Schema untereinander schreiben.
Oder per SQL-Update in die Tabelle einfügen.

Memo-Textfelder sind etwas unhandlich für eine automatische Auswertung.
Vielleicht hat ja Ohrkester direkt einen Vorschlag für eine Historientabelle.

maike

 

Ich bin ein Freund der kompletten relationalen Datenhaltung. Für solche Spässe halte ich das auch so, dass ich die Daten relational, nicht zusammengewürfelt vorhalte und ausschliesslich mit diesen Arbeite. Also in diesem Fall eine Preishistorietabelle mit z.B. dem genannten Gültigkeitsdatum.

Je nach Häufigkeit der Abfrage eines Zusammenzugs eines Artikels oder gar vielen Artikel sowie der Komplexität der Berechnung des Zusammenzugs entscheide ich mich dann für oder gegen ein eigenes Feld wo ein solcher Zusammenzugs zwischengespeichert wird. Solche berechneten aber statischen Felder sollte man z.B. mit einem eigenen Kürzel vor dem Feldnamen kenntlich machen.

Sobald sich etwas relevantes geändert hat, wird dann das Textfeld/Memofeld für diesen Datensatz komplett neu erstellt. Bei Serienänderungen wird das Feld für alle Datensätze oder alle beteiligten Datensätze der Kategorie neu berechnet.

Vorteil dieser herangehensweise ist einerseits die Geschwindigkeit mit dem der Auszug verfügbar ist und andernseits kannst Du die Art des Zusammenzugs jederzeit ändern und neu aufbauen, da ja alle Daten in relationaler Form vorhanden sind.

Soviel zur Theorie. Für Dein Problem würde ich nun also nach einem Speichervorgang eines neuen Preises ein Abfrage erstellen welcher den Zusammenzug macht und anschliessend das Memo per Update-Query Updaten.
Testen kannst das gut mit dem Abfragen-Designer. Den Quelltext der Abfrage kopierst dann z.B.raus und führst ihn mittels VBA und den entsprechenden Parameter aus.

 

Servus Weingeist,

Das sind wir alle.
Allerdings gibt es auch da Grenzen z.B. schon bei den Normalisierungen.
Die einen philosophieren über die Atomisierung der Daten, während andere
sagen, es muss erst einmal geklärt werden, ab wann diese absolute Atomisierung noch sinnig ist. Typisches Beispiel sind Strassennamen und Strassennr. getrennt oder nicht, mehrfache Vornamen bleiben ein Atom oder werden noch unteratomisiert.
Man kann es also auch übertreiben, wenn man das Ziel der Aufgabe nicht im Auge behält.

Wie ja schon vorgeschlagen.

Berechnete Felder (neues Feature) in Tabellen verstossen aber gegen das Gesetz der Redundanz ebenso, wie auch die bisher angewendeten Methoden, in fest vordefinierten Feldern die Berechnungen aus entsprechenden Abfragen abzulegen.
Ich sehe da also auch bei Dir eine Verletzung Deines so "hehren Versuches",
doch keines falls das Prinzip der Relationalität zu verletzen.

Was stünde denn da dann drin? Memofeld klingt für mich aber sehr nacht nicht normalisierten Daten.

Das verstehe ich gar nicht. Weder den Geschwindigkeitsvorteil, noch usw.

Gibts vielleicht ein kl. Beispiel als Demo DB für mich Schwerversteher?
Ich bemühe mich auch, in der nächsten Woche ein Beispiel meiner Idee
einer "leicht aufgeweichten Relationalität im Bereich von Rechnungen bei einfachen Datenbanken" zu erstellen.

 

Preishistorie: Sag ich ja, würde ich genauso machen.

Natürlich sind die Daten in so nem Memo nicht wirklich normalisiert. Die sind genauso wie man sie haben will, dass man ned ne komplizierte Abfrage braucht.

Ist ja z.B. oft üblich bei Warenbeständen, weils einfach keinen Sinn macht, das bei jeder Abfrage neu über sämtliche Buchungen zu berechnen wenn extrem viele Anfragen kommen.

Ob es tatsächlich Sinn macht, muss man im Einzelfall prüfen. Bei ner Preishistorie sehe ich das eher weniger, weil man vermutlich meist einen Artikel isoliert anschaut. Kann ich aber so nicht beurteilen, kommt auf die Abfragefrequenz, Anzahl Nutzer und das "Schnelligkeitsbedürfnis" an.
Also logischerweise erstmal mit normalisierten Daten, Abfragen, Indexoptimierungen arbeiten. Wenn man merkt die Performance ist immer noch zu mies, muss eben eine "Krücke" programmiert werden. Oder schöner ausgedrückt, ein perfekt angepasstes, benutzerdefiniertes Indexfeld =)

--> Ist zwar doppelte Datenhaltung, die Nutzdaten sind aber nicht "unsicher", weil der "Index" jederzeit neu aufgebaut werden kann. Auch wird keine direkte Datenmanipulation aus Benutzersicht daran vorgenommen.


Ich mache das z.B. gerne als Basis für eine Volltextsuche. Also alle für einen bestimmten Zweck relevanten Infos in ein gemeinsames Feld speichern. z.b. Adresse, Name, Kunden-Nr., bevorzugte Kontaktperson, Kundenkategorie etc. Je nach dem ne eigene Tab oder in der eigentlich Basistab. Danach im Suchformular eine Volltextsuche mit X-beliebigen Wörter.
Über alle Felder oder sogar mehrere Tabellen is das absolut unbrauchbar, mit einem solchen erzwungenen Index-Feld ist das super performant.

Bei ner richtigen Server-Datenbank ist das weit weniger kritisch als bei Access, weil ned immer alles komplett übertragen werden muss und der Server von RAM und CPU profitiert. Aber auch die zwingt man mit Volltextsuchen am einfachsten in die Knie.

 

Volltextsuche??
Das ist nun die absolute Gegenrichtung zur Normalisierung (1. NF atomare Informationen) und in den allermeisten Fällen ein Performancekiller.

Wenn ich Zucker brauche, operiere ich ihn besser nicht aus einer Kakaokuchenmischung, sondern nehme ihn einfach aus der Zuckertüte.

 

Wie sieht den der "VBA Code" aus wenn ich trotz aller Redundanz die Infos der Preishistorie für einen Artikel in ein Memofeld oder Textfeld mit Zeilenumbruch und Datum speichern möchte.

 

Ich möchte noch einmal vor dem Zusammenpappen von Informationen warnen. Die Accessforen sowie auch Excelforen sind übervoll mit Anfragen zu Problemen mit Datenkonglomeraten (zusammengesetzte Artikelnummern, Registrierungscodes uva.) und den Umgang damit. Probleme fangen da schon bei gezieltem Sortieren an, weil da Texte und Zahlen sich unterschiedlich verhalten. Solche Probleme hat man reichlich weniger, wenn man Informationen atomar lässt und Einzelspalten verarbeitet.

Zusammensetzen ist einfacher als Trennen. Wenn es schon Probleme beim Zusammensetzen gibt - und da scheinen viele ihre "Kreativität" so richtig ausleben zu wollen - wie soll dann das Herauslösen von dann doch wieder interessierenden Informationen funktionieren?
Für den Urheber mag es vielleicht uninteressant sein. Der nächste muss aber mehr mit solchen Daten machen und hat dann an dem Knochen zu kauen.

Daher würde ich meinen, wer ohne Not Einzelinformationen in einer Datenbank konkateniert (ausgenommen reine Ausgabezwecke), der sollte auch gleich die Routinen zur Entschlüsselung und Auswertung des Konkatenats mitliefern, ersatzweise eine Vermögensschadenshaftpflicht abschließen und mindestens 10 Jahre mit Beiträgen bedienen.

Letztlich: Selbst wenn das Vereinzeln der Informationen nicht das Problem ist, stirbt dann durch die Berechnungen eine Indexnutzung (wer denkt denn auch an so etwas?) und damit richtige Datenbankarbeit. Ich frage mich, wer mit vollem Bewusstsein bei seinem Neuwagen Gang 3 bis 6 blockiert, weil er in seinem momentanen Blickfeld nur von Ampel zu Ampel kriechen will?

Nicht speichern, aber erzeugen für Ansicht, Ausdruck und ggf. Export:
ADOSQLListe, geht rasant.

 

Natürlich. Aber halt das, was die Anwender gerne haben wollen. Inklusive mir. *wink.gif*

Dem kann ich nur zustimmen.
Wenn man das tatsächlich braucht, so wie oben vorgeschlagen.


@TO: Zeig doch mal Deine aktuelle Datenstruktur und beschreibe was genau Du wo gespeichert hast und was Du wo konsolidiert haben möchtest.

Für Eingabe- und Mutationsformular sind nur sinnvoll normalisierte Daten brauchbar. In den meistens Fällen auch
Auf Basis dieser Daten kannst Du allfällige nichtnormalisierte Datenfelder/Tabellen berechnen, neu erstellen etc. wenn es tatsächlich gebraucht wird. Alles andere ist wirklich quatsch.

 

Private Sub Befehl186_Click()

Me.Material.Einzelteile! Material = Me.Bezeichnung

End Sub


was ist hier falsch?
Material = Feld im Ufo
Einzelteile = Unterformular (Name)
Bezeichnung = Feld im Hfo

Vorschalg war

me.DeinUnterformularStuerelement.Form!FeldImUfo = me.DeinFeldimHfo