Office: (Office 2016) Edit Datensatz

Hallo,
ich habe mal eine generelle Frage zum Editieren von Datensätzen:
Im Beispiel habe ich ein Formular zum Erfassen/Editieren und Löschen von Datensätzen erstellt. In diesem befindet sich ein Unterformular im unteren Teil, in welchem ich durch alle Datensätze in Tabellenform scrollen kann.

Also zum Bsp.: habe ich im sfm die Felder:
txtArtikelname, txtEigenschaft1, txtEigenschaft2 und im frm die Felder
txtArtikelnameS, txtEigenschaft1S, txtEigenschaft2S

Durch Doppelklick im sfm übernehme ich die Daten des ausgewählten DS ins frm.
Nach Änderung der Daten speichere ich den Datensatz durch Anklicken eines Buttons "Save" wieder ab, in dem ich einfach die Daten aus dem frm wieder ins sfm schreibe. Leider kommt dann für die Felder, die ich nicht geändert habe, immer der Laufzeitfehler 3020: "Update oder CandelUpdate ohne AddNew oder Edit". Deshalb frage ich jedes Feld vorher ab, ob es sich geändert hat. So also z.B.:

Code:

So funktioniert es auch aber:
Für mich stellt sich hier die Frage, warum man nicht einfach den Datensatz auch bei keiner Änderung, also mit gleichem Wert überschreiben kann, bzw. ob ich eventuell bei Änderung des Datensatzes das völlig regelwidrig mache und es eigentlich nur über einen DAO-Befehl erfolgen sollte. Wenn ja, wie würde der bei diesem kleinen Beispiel aussehen.
VG Jens

:)

 

Hallo,
warum nimmst Du nicht einfach gebundene Formulare, da kannst Du Dir das ganze VBA Gedöns (fast) ersatzlos sparen. Du verschenkst einer der großen Vorteile von Access.

Wobei die Aufzählungsfelder (txtEigenschaft1, txtEigenschaft2) auch ein Strukturfehler in der Datenbank ist. Die zutreffenden Eigenschaften sollten als je ein Datensatz in eine extra Tabelle. Zusätzlich noch eine Tabelle mit allen möglichen Eigenschaften. Das wäre dann eine n:m Beziehung zwischen Artikel und Eigenschaft.

 

Hallo Klaus,
danke für die Antwort. Ja, es sind ja auch noch Tabellen dahinter und im frm sind cbo's dafür, aber ich wollte jetzt das Beispiel nicht verkomplizieren, da das auf meine Frage keine Auswirkung hat. Kannst du mir mal auf meine Frage noch deine Meinung schreiben?
VG Jens.

 

Hallo Tuan,

da man nicht genau weiß, was du da im einzelnen gemacht hast, wäre es von Vorteil, wenn du ein Beispiel hier hochläds.

Wenn du schon mit einem ungebundene Formular arbeiten möchtest, solltest du die CRUD-Operationen schon mit SQL umsetzen und danach ein Requery für das UF machen.

Gruß Ulrich

 

Hallo,
zu deiner Frage habe ich keine Meinung. Dein Beitrag in #3 ist auch eher verwirrend als hilfreich.
Ich kann nur auf gebundene Formulare hinweisen, da dürfte sich dann Deine Frage in Luft auflösen.

Und meine Frage, warum keine gebundenen Formulare hast Du ja auch nicht geantwortet.

 

Hallo Klaus und Ulrich,
also das sfm ist ja ein gebundenes Formular. Nur das frm ist nicht gebunden, da ich wirklich erst bei Drücken von "Save" den Datensatz speichern will und so kann ich im frm "wild" darauf los ändern, ohne das es gleich gespeichert wird.

Ich werde mal ein Bsp. schreiben und es posten. Das dauert aber eine Weile, da ich heute keine Zeit mehr dafür habe.
Danke euch erst mal.
VG Jens.

 

Welcher Code wird denn damit ausgeöst?

 

\@Tuan
Du kannst auch mit einem gebundenen Formular das automatische Speichern verhindern, völlig problemlos.

 

So, habe jetzt mal eine Test-Datenbank erstellt. Bitte nicht die Fehlermeldung beim Öffnen beachten. Habe noch nicht gefunden wo hier sich noch was versteckt hat. Die Datenbank geht genau so wie ich es will:
Unten im sfm habe ich eine Tabelle, durch die ich scrollen kann. Oben im frm habe ich ein Suchfeld falls ich den Artikelnamen weiß oder einen neuen anlegen will. Durch Doppelklick auf einen DS im sfm oder durch Return im sfm in einem Datensatz wähle ich den zu editierenden DS aus, kann ihn im frm editieren oder löschen.
Wichtig: Die Button "Save", "Cancel", und "Delete" darf ich von der Ansicht und Funktion her nicht ändern. (Code schon)

Was mich stört ist nun die komplizierte Speicherung besonders der cbo-Felder:
Code:

Frage 1:Hier möchte ich eigentlich auch wieder das Feld wirklich leeren können und nicht durch die leere Produktgruppe 3 füllen. Wie geht das?

In meiner richtigen Tabelle habe ich ca. 20 cbo-Felder für einen Artikel.

Frage 2:Geht das mit dem Speichern irgendwie anders und ja Klaus, wenn es mit gebundenen Formularen besser geht, gern, aber wie?
Wie gesagt, das Handling der Tabelle soll so bleiben.
Da ich nicht so fit in Access bin, nur alles autodidaktisch angeeignet, wäre ein Umschreiben meines Bsp. natürlich toll.

VG Jens.

 

Das deutet auf Nachschlagefelder hin. Nicht zweckmäßig - warum? Hier lesen.
Wie auch Klaus bin ich auch der Meinung, hier liegt ein völlig ungeeignetes Datenmodell vor. Daher habe ich es unterlassen, mir die DB anzusehen.

 

Hallo,
das deutet nicht nur auf Nachschlagefelder hin, sondern auf ein völlig ungeeignetes Datenmodell.
Was steht denn in diesen 20 cbo Feldern?
Das Beispiel ist viel zu sehr abgemagert. Wenigstens einige dieser 20 cbo Felder sollten im Beispiel sein.

 

Hallo Elmar und Klaus,
nein, ich habe keine Nachschlagefelder verwendet. (Dachte das erkennt man.) und die anderen cbo's sind genau solche wie im Beispiel dargestellt. Ob ich da noch 1 oder 2 oder 3 dazu schreibe ist doch egal. (z.b. Hersteller, Lagerfach, Material, Farbe usw. - alles durch extra Tabellen hinterlegt)

Mir geht es ja darum, wie du, Klaus, das Beispiel anders mit gebundenen Formularen lösen würdest, bzw. wenn nicht, ob es dann eine bessere Lösung für das Beispiel der cbo-Speicherung gibt?

Wenn in meinem Beispiel das Datenmodell völlig ungeeignet ist wäre ich auch hier über ein Tip dankbar.

VG Jens.

 

Hallo,
zeige mal ein Bild des Beziehungsfensters, damit man eine Vorstellung hat wie das zusammenhängt.

 

So hier das Beziehungsfenster. Die Originaldatei darf ich nicht hochladen aus Datenschutzgründen, da bekomme ich Ärger. Aber es ist wirklich soooo eine einfache Beziehung. Könnte ich auch mit Excel machen, aber ich will mich ja mal an Access wagen.
Fragen bleiben die Gleichen
VG Jens.

 

Hallo,
Die cbo Speicherung ist mit den hier gezeigten 4 Feldern OK. Was ist dann die restlichen 16 (Du sprachst ja von 20) ?

Hersteller und Lieferant solltest Du in einer Tabelle zusammenfassen, zumal es vorkommen kann, dass der Hersteller auch der Lieferant ist.
In dieser einen Tabelle dann kommt ein Feld für ein Kennzeichen (1=Hersteller, 2=Lieferant, 3=Beides), dann kannst Du die Tabelle auch ganz einfach filtern.
Und ja, Feldname "Name" ist ungeeignet (siehe Hinweis von Elmar, hatte ich übersehen). Da gibt Access auch einen Warnhinweis aus, hast Du dann ignoriert.

Du wolltest auch ein Unterformular einsetzen, mit den gezeigten Beziehungen macht aber ein Ufo keinen Sinn. Was willst Du denn im Ufo anziegen ?


PS:
Nenne die IDs nicht einfach ID, sonst hast Du doppelten Namen in der DB (was man vermeiden sollte), außerdem weißt Du ja dann selbst nicht welche ID nun gemeint ist.
ProdGruppeID, HerstellerID, LieferantID, FarbeID wäre da deulich übersichtlicher.