November 24, 2020, 07:52:57

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


"Standardwert aus vorherigem Datensatz" funktioniert nicht richtig

Begonnen von Rainer 1984, November 27, 2011, 16:04:05

⏪ vorheriges - nächstes ⏩

Rainer 1984

Hallo Accessianer,

die Funktion "Standardwert aus vorherigem Datensatz" (Donkarl 4.22 -> bei Textfeldern) scheint nicht richtig zu funktionieren.
Nur wenn das Formular offen bleibt, wird bei der Erzeugung eines neuen Datensatzes der aus dem letzten Datensatz von mir geänderte Wert übernommen (z.B. der Begriff "Wort2").
Schliesse ich das Formular und öffne es erneut, wird wieder der unter "Standardwert" eingegebene Wert (z.B. "Wort1") angezeigt.
Lösche ich den Wert unter "Standardwert", wird natürlich gar nichts angezeigt.

Wie kriegt man es hin, dass bei jedem NEUEN ÖFFNEN des Formulars der Wert aus dem LETZTEN Eintrag übernommen wird (eben der Begriff "Wort2")? Ist das überhaupt die richtige Funktion dafür?

Vielen Dank und viele Grüße

Ratloser Rainer

MzKlMu

Hallo,
das beschrieben Verhalten ist normal. Um den Standardwert dauerhaft zu speichern, muss das Formular im Entwurf geöffnet sein und dann der Entwurf gespeichert. Wenn das Formular geschlossen wird, so wie Du es hast wieder der alte Standardwert gesetzt bzw. nichts gesetzt.
Besser ist es daher den Standardwert aus der Tabelle zu holen.
Der letzte Datensatz muss in einer Tabelle aber nicht zwangläufig der zuletzt eingegebene DS sein.
Daher muss der letzte Datensatz definiert werden, z.B. höchstes Datum, höchste ID etc.

Dann kann man mit DLookup den letzten Wert holen und als Standardwert setzen.
Gruß
Klaus

Rainer 1984

Hallo MzKlMu,

zunächst vielen Dank für Deine Antwort.

Ich dachte DLookup (DomWert) soll gemieden werden, da Ergebnisse aus allen Datensätzen errechnet werden müssen und das zeitintensiv ist.

Wie ist es mit DLast (DomLetzterWert)?

Viele Grüße

Rainer

MzKlMu

Hallo,
ZitatIch dachte DLookup (DomWert) soll gemieden werden, da Ergebnisse aus allen Datensätzen errechnet werden müssen und das zeitintensiv ist.
Du brauchst in diesem Fall ein Wert, was soll daran zeitintensiv sein?

DomLetzterWert geht nicht, hier wird ein zufälliger Wert aus einer Tabelle ermittelt. Das kannst Du auch in der Hilfe lesen.
Du musst DLookup verwenden, mit einem Kriterium das den letzten Datensatz bestimmt. Die Spalte für das Kriterium sollte indiziert sein.
Gruß
Klaus

Rainer 1984

Hallo MzKlMu,

Zitat...was soll daran zeitintensiv sein?

bin jetzt ein wenig verunsichert.

Habe folgende Zitate aus meinem letzten Thema gefunden (Rückgabe des Checkboxwertes in einem anderen Formular):
ZitatÜbrigens, die häufige Verwendung von DomWert deutet auf ein falsches Datenmodell hin. DomWert gehört zu den Befehlen die man vermeiden sollte.

ZitatDomwert bremst die DB aus. Mit Domwert wird aus der DB eine lahme Ente.


Habe deshalb damals meine gesamten DomWerte in die Tonne getreten und gegen Formularabfragen getauscht.

Viele Grüße

Rainer

MzKlMu

Hallo,
ich kann mich erinnern, aber damals sollten ja alle Felder eines Formular auch geschrieben werden.
Und damals gab es ja auch eine Alternative, nämlich gebundene Formulare.
Eine solche Alternative gibt es aber für den Standardwert nicht.
Zumindest wüsste ich keine, außer wie gesagt, das Formular im Entwurf öffnen und den neuen Wert mit dem Entwurf speichern.

Wenn Du einzelne Werte aus einer Tabelle holen willst, brauchst Du DLookup.
Gruß
Klaus

Beaker s.a.

Hallo,

ZitatWenn Du einzelne Werte aus einer Tabelle holen willst, brauchst Du DLookup.


Und wenn's zu langsam ist, gibt es ja auch diverse Alternativen die Aggregatfunktionen per Code auf einen Zugriff per Recordset umzubiegen.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

MzKlMu

Hallo,
ZitatAggregatfunktionen per Code auf einen Zugriff per Recordset umzubiegen
Das dürfte dann aber eher noch langsamer sein.
Gruß
Klaus

Rainer 1984

Hallo MzKlMu,

werde das Problem in dem Fall mit DomWert lösen.

Vielen Dank für Deine Hilfe.

Viele Grüße

Rainer

Beaker s.a.

Hallo,

@MzKlMu
Zitat
ZitatAggregatfunktionen per Code auf einen Zugriff per Recordset umzubiegen

Das dürfte dann aber eher noch langsamer sein.

Hm, da habe ich in den letzten Jahren aber anderes gelesen, - oder nicht verstanden ;-)

@Rainer
Zitatwerde das Problem in dem Fall mit DomWert lösen

Das musst Du dann aber "von aussen" machen. Wenn Du das als Steuerelementeinhalt eingibst, kannst Du das Feld nicht mehr manuell ändern, und der Wert wird auch nicht automatisch in der Tabelle gespeichert.
Ich frage mich eh, warum Du zur Laufzeit den Standardwert eines Feldes ändern willst. Ein Standard ist doch ein Wert, den man nur in Ausnahmefällen ändert, oder damit man in Feldern mit "Eingabe erforderlich" nicht auf einen entsprechenden Fehler läuft, und deshalb IMO auch auch schon auf Tabellenebene vergeben werden sollte.
Wenn es darum geht die Eingabe zu erleichtern, könntest Du deinen Anwendern vielleicht die Tastenkombination "Strg#" näherbringen. Die schreibt in ein Textfeld den gleichen Wert wie im vorigen DS. Wobei "voriger" der DS ist, der im Form vor dem aktuellen angezeigt wird. Ob das der letzte ist, entscheidet IMO die Sortierung.
hth
gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

DF6GL

Hallo,

naja, ein Recordset-Dlookup-Ersatz à la


Dim v as Variant
v=currentdb.Openrecordset("select Feld1 from Tabelle1 where IrgendeinZahlFeld =1",dbOpensnapshot)(0)


ist eine Kleinigkeit schneller als die Dlookup-Funktion..



Einen "dynamischen" Standardwert , ausgelesen aus einer Tabelle,  kann ich mir schon vorstellen, z. B. bei einem Fahrtenbuch, wenn bei einem neuen Eintrag  für den "StartKilometerstand" der "EndKilometerstand" des zuletzt gespeicherten Datensatzes übernommen werden, aber trotzdem änderbar sein  soll.  Aber auch hier steht und fällt das ganze Ding mit der Kenntnis des "Letzten" Datensatzes (siehe Anmerkungen von Klaus)

Wobei bei entspr. Aufbau des Forms dieser Wert auch aus dem Formular-Recordset geholt werden könnte.


Die Standardwert-Eigenschaft in der Tabelle dynamisch zu setzen gestaltet sich etwas schwieriger...


Beaker s.a.

Hallo Franz,

ZitatDim v as Variant
v=currentdb.Openrecordset("select Feld1 from Tabelle1 where IrgendeinZahlFeld =1",dbOpensnapshot)(0)
ist eine Kleinigkeit schneller als die Dlookup-Funktion..

Wollen wir nicht drüber streiten, da es wohl eh nur bei sehr grossen Tabellen relevant würde.

ZitatEinen "dynamischen" Standardwert , ausgelesen aus einer Tabelle,


Das wäre natürlich eine Lösung für den OP. Da könnte er beim Speichern des, dann bekannten letzten DS den neuen Standardwert wegspeichern, und beim nächsten Öffnen des Forms wieder auslesen.

ZitatEinen "dynamischen" Standardwert , ausgelesen aus einer Tabelle,  kann ich mir schon vorstellen, z. B. bei einem Fahrtenbuch, wenn bei einem neuen Eintrag  für den "StartKilometerstand" der "EndKilometerstand" des zuletzt gespeicherten Datensatzes übernommen werden


Schlechtes Beispiel,  - oder?
Wo könnten da den Lücken entstehen? Will sagen Endstand ist doch automatisch Anfangstand der nächsten Fahrt. Es reicht also ein Feld "Kilometerstand". Und da habe ich auch keine Probleme den letzten DS zu ermitteln, da bei dieser Anwendung eine fortlaufende Nummerierung IMO zwingend erforderlich ist. Es also gar nicht nötig den Standardwert zu manipulieren, da ist dann eben der letzte Wert der "Standardwert".
Falls ich mich hier auf dem Holzwege befinde, bitte ich um entsprechende Hinweise, - danke.
gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

DF6GL

Hallo Ekkehard,


natürlich hast Du Recht, es geht hier ja auch nur um die Theorie, bzw. das Prinzip  Bei dem "Fahrtenbuch" kann es schon zu Lücken kommen, je nachdem, für was so ein Fahrtenbuch (oder meinetwegen auch eine andere Logbuchfunktion) verwendet werden soll. Nicht jeder "Verbrauch" von Kilometern muss eine relevante (und demzufolge zu erfassende) Fahrt bedeuten .



Wie auch immer,  wir schweifen hier vom etwas vom OP-Thema ab...  ;)