UPDATE der Datensätze

[Flocko]

Hallo zusammen,

ich würde gerne in Access ein Formular erstellen, mit dem es möglich ist Datensätze zu überarbeiten.
Am besten wäre es wenn man mit Kombinationsfeldern die zu bearbeitende Tabelle bzw. Spalte auswählt. Anschließend wird noch eine weitere Spalte der zuvor gewählten Tabelle (per Kombinationsfeld) ausgewählt und ein Kriterium angegeben.

Zum Schluss sollen die Angaben so in einen SQL Befehl eingesetzt werden, damit dieser per Schaltfläche ausgeführt werden kann.

Bsp.

UPDATE Kombinationsfeld1
SET Kombinationsfeld2 = Textfeld1
WHERE Kombinationsfeld3 = Textfeld2

UPDATE tblPreisliste
SET Preis = 10€
WHERE Produktname = Fußball


Danke schon mal im voraus!   

[MzKlMu]

Hallo,
verwende ein gebundenes Formular, dann braucht es gar keinen Code.
Allenfalls zum Suchen eines bestimmten Datensatzes.

[Beaker s.a.]

Hallo,
Wenn du Klaus' Hinweis auf gebundene Formulare nicht folgen willst,
geht das IMO so (Luftcode):

Code [Auswählen] Erweitern

Private Sub DeinButton_Click()
    Dim strSQL As String

    strSQL = _
            "UPDATE " & Me!DeinKombi1.Column(n) _
          & " SET " & Me!DeinKombi2.Column(n) & " = " & Me!Textfeld1 _
          & " WHERE " & Me!DeinKombi3.Column(n) & " = " & Me!Textfeld2 _
    CurrentDb.Execute strSQL

'.Column(n) ist jeweils die Spalte in der die Namen der Tabelle und der
'Felder stehen (1.Spalte = 0)
'Wenn Textfeld2 vom Typ String ist, müssen da dann noch " ' " drumrum:
'& " WHERE " & Me!DeinKombi3.Column(n) & " = '" & Me!Textfeld2 & "'"

End Sub
Füge vor dem .Execute noch ein Debug.Print ein, um den SQL-String auf
korrekte Syntax zu überprüfen.

hth, auch wenn sich mir (Klaus wahrscheinlich auch) der Sinn nicht erschliesst.
gruss ekkehard

[Flocko]

Vielen Dank für die Antwort.

Ist es möglich ein gebundenes Formular zu verwenden wenn ich über dieses Formular auf alle Tabellen zugreifen möchte?

@Beaker s.a, dein Code sieht vielversprechend aus, ich denke damit könnte es so funktionieren wie ich mir das vorstelle.

Leider funktioniert ein Schritt davor noch nicht ganz.

Das Kombinationsfeld1 zeigt jetzt eine Auswahl aller Tabellen der DB. Das Kombinationsfeld2 soll nun nur eine Auswahl der Spaltennamen der im Kombinationsfeld1 angegebenen Tabelle anzeigen. Kann mir da noch jemand helfen.

Ich freue mich über jede Hilfe

[MaggieMay]

Hallo,

du kannst die Datenfelder einer Tabelle über Zugriff auf die Tabledefs-Auflistung auslesen.

Beispiel:

Code [Auswählen] Erweitern

Dim tdf As DAO.TableDef, fld As DAO.Field
Set tdf = CurrentDB.Tabledefs(kombifeld1)
For Each fld In tdf
    strFeldliste = strFeldliste & "," & fld.Name
Next
Me.kombifeld2.RowSource = Mid(strFeldliste,2)
Me.kombifeld3.RowSource = Me.kombifeld2.RowSource

[Beaker s.a.]

Hallo Flocko,
Siehst Du da ist die Lösung.
Du musst dazu allerdings die Eigenschaft "Herkunftstyp" auf "Werteliste"
einstellen. Hat Maggie vergessen zu erwähnen.

Der Nachteil dieser ganzen Konstruktion ist allerdings, das du keine
Fremdschlüsselfelder automatisch setzen kannst. Im Prinzip funzt so
keine DB, da dem Anwender alle Beziehungen zwischen Tabellen bekannt
sein müssten. Wie willst du denn so z.B. auch nur einen neuen DS anlegen?

Ist es möglich ein gebundenes Formular zu verwenden wenn ich über dieses Formular auf alle Tabellen zugreifen möchte?

Das geht entweder mit dem so genannten Navigations-Formular, das es
seit A2007 gibt, welchens m.E. aber nur sperrig zu handeln ist.
Oder du baust dir das selber. Dazu nimmst Du ein Formular (erstmal ungebunden)
und plazierst ein Registersteuerelement darauf. Auf die einzelnen Register
kommen dann die Felder der zu bearbeiteten Tabelle. Dann wird beim
Klick auf die Register die Datenherkunft des Formulars auf die entsprechende
Tabelle eingestellt. Das ist beim Entwurf ein bisschen Aufwand, weil du das
einmal manuell machen musst, um den Steuerelementinhalt der Formular-
felder auf die entsprechenden Felder der Tabelle einzustellen.

Falls du dabei Hilfe brauchst, müsstest du uns ein Bild des Beziehungs-
fensters mit allen Tabellen und allen Feldern posten.
Vielleicht (oder höchstwahrscheinlich) müssen da auch noch Unterformulare
mit drauf.

gruss ekkehard

[Flocko]

Vielen Dank nochmal für die Hilfe.

Ich habe mein Formular jetzt ein bisschen umgeändert. Man kann jetzt mit dem Kombinationsfeld1 aus allen Tabellen die gewünschte wählen. Anschließend muss der Name der zu bearbeitenden Spalte und der neue Wert in ein Textfeld eingegeben werden. Und in einem dritten und vierten Textfeld wird die Spalte mit Bedingung angegeben.

Den Code von ekkehard habe ich also folgendermaßen angepasst:

Private Sub Update_Click()

    Dim strSQL As String

    strSQL = "UPDATE " & Me!Kombinationsfeld0.Column(0) & " SET " & Me!Spaltenname1 & " = " & Me!Wert1 & " WHERE " & Me!Spaltenname2 & " = '" & Me!Wert2 & "'"
    CurrentDb.Execute strSQL
End Sub

Hier ist noch das Problem, dass dem Code nicht egal ist ob im Textfeld eine Zahl oder Text steht, kann man das noch anpassen?

Für den Anlauf mit den Kombinationsfeldern habe ich gedacht man könnte mit einem SELECT Befehl in dieser Art arbeiten, um im Kombifeld2 nur die Spaltennamen der im Kombifeld1 angegebenen Tabelle anzeigen zu lassen.

SELECT column_names FROM CurrentDb WHERE table_name = " & Me!Kombinationsfeld0.Column() & "

Weiß jemand wie man den SELECT Befehl anpassen könnte?

Grüße Flocko

[Beaker s.a.]

Hallo Flocko,
Muss jetzt leider weg, deshalb nur noch ganz kurz.

Zahl oder Text; - schau mal in die OH oder gurgel nach
BuildCriteria

Feldliste per SQL; - die sollte irgendwo in den Tiefen der Systemdateien
verborgen sein. Und ich bin auch ziemlich sicher, das man die auslesen kann;-
weiss allerdings nicht wie. Falls das doch nicht geht, hilft auf alle Fälle
Maggies Code.

gruss ekkehard

[DF6GL]

Hallo,

@Flocko:

könntest Du (nochmal) die hinter dieser Vorgehensweise steckende Aufgabe erläutern?

Soll heißen: was willst Du insgesamt und im Grunde denn überhaupt machen?

[Lachtaube]

Hallo,

das Vorhaben ist zwar eher seltsam, sollte aber mit einer "echten" Parameterabfrage gelingen.

Code [Auswählen] Erweitern

Private Sub Update_Click()
   Dim strSQL As String

   On Error Goto e
   strSQL = "UPDATE " & Me.Kombinationsfeld0.Column(0) & _
            "    SET " & Me.Spaltenname1 & " = [@Param1] " & _
            " WHERE " & Me.Spaltenname2 & " = [@Param2]"
   With CurrentDb().CreateQueryDef(vbNullString, strSQL)
      .Parameters("Param1") = Me.Wert1
      .Parameters("Param2") = Me.Wert2
      .Execute dbFailOnError
   End With
   Exit Sub

e:
   MsgBox Err.Description
End Sub[/font]

[Flocko]

Eigentlich ganz einfach. Ich will es mithilfe des Formulars ermöglichen Datensätze in bestimmten Tabellen zu ändern. Beispielsweise wenn ich eine Tabelle mit Produktkosten habe und ich dann den Preis von einem bestimmten Produkt ändern will...
Der Nutzer soll dann zuerst mit einem Kombifeld die Tabelle, dann die Spalte und dann das Kriterium angeben können.

Ich hoffe es ist halbwegs verständlich

[MzKlMu]

Hallo,

Der Nutzer soll dann zuerst mit einem Kombifeld die Tabelle, dann die Spalte und dann das Kriterium angeben können.

da erhebt sich die Frage, hast Du Produktpreise in mehreren Tabellen ?
Normalerweise führt man eine Preisliste als Tabelle mit einem Fremdschlüssel zum Produkt und einem FS zum Lieferant sowie einer Spalte für das DatumAb und den eigentlichen Preis. Dazu braucht man ein Formular das man entsprechend filtert, da muss man weder Tabellen noch Spalten wählen.
Spalten ist noch merkwürdiger, für den Preis gibt es eine Spalte auf immer und ewig für beliebig viele Produkte und Lieferanten.

Mir scheint, da wäre eher das Datenmodell zu überdenken.

[DF6GL]

Hallo,

ich finde dann, die Beschreibung zu Grunde legend,das Vorgehen schlichtweg Quatsch, um es deutlich zu sagen.


Wenn mit einer Db gearbeitet werden soll, dann ist es der einfachste, sicherste und erfolgreichste Weg, lediglich die Standard-Möglichkeiten von Access zu nutzen.  Das bedeutet hier:

Sich ein paar Gedanken um die vorhandenen Daten zu machen,  diese zu normalisieren und in Tabellen zu übertragen. (Normalisierung).  Eine Überlegung zum Arbeitsablauf ist auch nicht verboten.

Sodann für jede Tabelle ein (gebundenes) Formular (auch mit dem Assistenten) erstellen und fertig ist die Laube.  Ein paar Feinheiten (Auswahl-Kombis,  HFO-UFO-Konstruktion) sind dann problemlos einzubauen. Dafür sind dann die Gedanken zum Arbeitsablauf nützlich.

[Beaker s.a.]

Hallo,

@Franz

ich finde dann, die Beschreibung zu Grunde legend,das Vorgehen schlichtweg Quatsch, um es deutlich zu sagen.

Hatte ich, wenn auch weniger deutlich, auch schon geschrieben:

Im Prinzip funzt so keine DB,

@Lachtraube
Die Abfrage ist nicht das eigentliche "Problem", sondern die RecordSource
des Kombis, das die Felder der im 1. Kombi ausgewählten Tabelle anzeigt.
Ausserdem haben Parameter auch einen festgelegten Datentyp, womit sich
das Problem Zahl/String nicht lösen lässt.

Zur Feldliste hat Maggie aber bereits eine praktikable Lösung gepostet.
Zum Datentyp gab ich den Hinweis auf BuildCriteria. Ich kann das
jetzt nicht so aus dem Ärmel schütteln, schau's mir aber morgen selber
noch mal an. Auch wenn's, wie mehrfach gesagt, nicht wirklich sinnvoll
ist, stimme da Klaus und Franz absolut zu. Aber, des Menschen Wille ist
sein Himmelreich 

gruss ekkehard

[Lachtaube]

@ekkehard,

Wenn als Herkunftstyp eines Kombi-/Listenfelds Feldliste eingestellt ist, und die Datensatzherkunft auf eine Tabelle oder gespeicherte Abfrage festgelegt wird, so werden die Feldnamen angezeigt.

Die Tabellen bzw. Abfragen könnte man sich in ein Kombi- oder Listenfeld u. a. mit den bekannten Abfragen vom Access Web Return database object names ziehen.

Ich stelle aber auch in Zweifel, dass das angestrebte Formular von einem Anwender intuitiv zu bedienen ist.

Generell sollte man das Editieren von Daten immer in Frage stellen. Die Notwendigkeit eines Editierens würde ja bedeuten, das die vorherigen Daten schlichtweg falsch oder unvollständig waren. Bei Rechtschreibfehlern mag das ja noch durchgehen.

Ändert sich im Laufe der Zeit ein Item eines Objekts, so sollte dies besser in einem Detaildatensatz geschehen, damit alte und neue Daten nach wie vor Bestand haben und z. Bsp. Berichte, die letzten Monat noch richtig waren, auch nach der Änderung noch die selben richtigen Daten ausgeben.

Mein Fazit wäre demnach, dass das Datenmodell (noch) nicht ausgereift ist.