April 18, 2021, 01:55:16

Neuigkeiten:

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


Datensatz löschen - Verhindern, dass nächste DS angezeigt wird

Begonnen von Nic-O, Mai 04, 2015, 11:36:44

⏪ vorheriges - nächstes ⏩

Nic-O

Guten Tag zusammen,

nachdem mir bei meinem anderen Problem so schnell geholfen wurde, versuche ich es doch gleich noch einmal.

Meine DB läuft mit Audit Trail (Tool zum Änderungstracking).

Problem 1:
Wenn ich einen Datensatz lösche, dann springt er beim Löschen zum nächsten Datensatz, während der Hauptname des Datensatzes immer noch in einem DropDown-Feld vorhanden ist. Das ist für die Anwender sehr irritierend.

Problem 2:
Der Datensatz wird zwar gelöscht, aber in der Audit Trail Tabelle nimmt er den Namen des nächsten Datensatzes und nicht den eigentlich gelöschten.

Meine Theorie:
Wenn ich das 1. Problem behebe, erübrigt sich das 2. Vielleicht

Gruß,

Nico

DF6GL

Hallo,


1)  Da dürfte ein Requery des Kombifeldes helfen...

2) Da dürfte es sich um ein Logikproblem in der Audittrail-Programmierung handeln...

Nic-O

Hallo Franz,

wie soll der Requery gesetzt werden? Nach dem Update oder?

Bsp.:

Private Sub mForm_AfterUpdate()
    RequeryComboBox
End Sub

gruß,
Nico

MaggieMay

Hi,

eher so:Private Sub Form_AfterUpdate()
    Me!ComboBox.Requery
End Sub


Punkt 2 hat aber vermutlich nichts damit zu tun. Wann und wie wird das Audit-Trail geschrieben?
Freundliche Grüße
MaggieMay

Hondo

Hallo,
ich geh auch davon aus dass Auditrail zu spät geschrieben wird, nämlich wenn der DS bereits gelöscht ist.
Du musst dafür sorgen dass das Löschen bestätigt werden muss über Optionen/Client-Einstellungen/Bestätigen->Datensatzänderungen.

Dann kannst du Audittrail wie folgt aufrufen:
Private Sub Form_AfterDelConfirm(Status As Integer)
    If Status = acDeleteOK Then Call AuditChanges("DatensatzID", "DELETE")
End Sub


Nachzulesen hier ganz unten:
http://www.fontstuff.com/access/acctut21.htm

edit/
Mit DatensatzID ist gemeint der Feldname des DatensatzID des gebundenen Formulars.

Gruß Andreas

Hondo

BTW: welches Audit-Trail verwendest du eigentlich?

Andreas

Nic-O

Ich weiß leider nicht welche Version das ist, da mein Vorgänger Praktikant dies ins Leben gerufen hat....

Anbei mal der Code des verwendeten Audit-Trail. Hat mir schon genug Probleme bereitet!! Habe nämlich versucht, diese Version und eine andere für Unterformulare zu nutzen. Hat leider nicht funktioniert...

Option Compare Database

Sub AuditChanges(IDField As String, UserAction As String)
    On Error GoTo AuditChanges_Err
    Dim cnn As ADODB.Connection
    Dim rst As ADODB.Recordset
    Dim ctl As Control
    Dim datTimeCheck As Date
    Dim strUserID As String
    Set cnn = CurrentProject.Connection
    Set rst = New ADODB.Recordset
    rst.Open "SELECT * FROM tblAuditTrail", cnn, adOpenDynamic, adLockOptimistic
    datTimeCheck = Now()
    strUserID = Environ("USERNAME")
    Select Case UserAction
        Case "EDIT"
            For Each ctl In Screen.ActiveForm.Controls
                If ctl.Tag = "Audit" Then
                    If Nz(ctl.Value) <> Nz(ctl.OldValue) Then
                        With rst
                            .AddNew
                            ![DateTime] = datTimeCheck
                            ![UserName] = strUserID
                            ![FormName] = Screen.ActiveForm.Name
                            ![Action] = UserAction
                            ![RecordID] = Screen.ActiveForm.Controls(IDField).Value
                            ![FieldName] = ctl.ControlSource
                            ![OldValue] = ctl.OldValue
                            ![NewValue] = ctl.Value
                            .Update
                        End With
                    End If
                End If
            Next ctl
        Case Else
            With rst
                .AddNew
                ![DateTime] = datTimeCheck
                ![UserName] = strUserID
                ![FormName] = Screen.ActiveForm.Name
                ![Action] = UserAction
                ![RecordID] = Screen.ActiveForm.Controls(IDField).Value
                .Update
            End With
    End Select
AuditChanges_Exit:
    On Error Resume Next
    rst.Close
    cnn.Close
    Set rst = Nothing
    Set cnn = Nothing
    Exit Sub
AuditChanges_Err:
    MsgBox Err.Description, vbCritical, "ERROR!"
    Resume AuditChanges_Exit
End Sub



MaggieMay

Hi,

der Code ist für Unterformulare nicht geeignet, dazu brauchst du im einfachsten Fall eine separate Prozedur mit entsprechenden Anpassungen, bspw. der Übergabe des Namens vom Unterformularsteuerelement.

Was das Lösch-Protokoll betrifft, so solltest du noch zeigen wo und wie das Audit-Trail aufgerufen wird.
Freundliche Grüße
MaggieMay

Nic-O

Guten Morgen,

hier der Code aus einem der Formulare:

'Änderungstracking LÖSCHEN
Private Sub Form_AfterDelConfirm(Status As Integer)
    If Status = acDeleteOK Then Call AuditChanges("Kunden_Name", "DELETE")
    End Sub


gruß,

Nico

Hondo

Ja das ist schon korrekt, funktioniert aber nicht im Unterformular.

Gruß Andreas

Nic-O

Ich habe meine Oberfläche so umgebaut, dass es keine Unterformulare mehr gibt.

Somit gibt es nur noch die 2 oben genannten Probleme :-)

MaggieMay

Hi,
ZitatIch habe meine Oberfläche so umgebaut, dass es keine Unterformulare mehr gibt.

das halte ich für die falsche Entscheidung, besser wäre es, die Prozedur zur Änderungsverfolgung anzupassen bzw. zu erweitern.

Und was das Protokollieren der Löschung betrifft, so ist "Form_AfterDelConfirm" offensichtlich das falsche Ereignis, weil da die Löschung bereits vollständig vollzogen ist.
Freundliche Grüße
MaggieMay

Nic-O

Ich habe mich mehr als eine Woche mit der Änderung des Codes der Änderungsverfolgung beschäftigt und ware es zum Schluss einfach leid. Von daher bereue ich es bis dato kein Stück :-)
Ich bin bis zu dem Punkt gekommen, dass er Änderungen gespeichert hat. Neue oder gelöscht Einträge konnten jedoch nicht oder nur falsch getrackt werden.

@MaggieMay:
was würdest du denn anstatt "Form_AfterDelConfirm" verwenden? In der offiziellen Doku zu dem Modul wird ebenfalls von dieser Art gesprochen.

Hondo

Hallo,
das Ereignis ist das richtige.
Zum Zeitpunkt wo der Bestätigungsdialog kommt ist die Änderung noch nicht gespeichert da dieser Dialog quasi Modal wirkt.
Ich hab diesen Audit-Trail als Klasse umgebaut, an der Unterformularfähigkeit bin ich noch am arbeiten. Das Funktioniert so dass die Controls des Hauptformulars durchlaufen werden bis ein UnterformularControl gefunden ist, dann wird der Prozess neu angestoßen mit dem SourceObject des Ufos und des IDFeldes welches z.B. als Tag gespeichert werden kann.

Sobald ich fertig bin veröffentliche ich es hier.

Gruß Andreas

DF6GL

Hallo,

Tipp:  Form-Ereignis "Beim Löschen" benutzen"
Währenddessen sind die zu löschenden Daten noch verfügbar..


Neue Daten:

Im BeforeUpdate-Ereignis auf neuen DS testen:

If Me.Newrecord Then
'Daten mit Kennung "Neuer DS" wegschreiben
Else
'Daten "normal" wegschreiben
End If

PS: das AfterDeleteConfirm-Ereignis tritt nur auf, wenn in den Optionen/Clienteinstellungen/Bearbeiten    Löschbestätigung   angehakt ist.