Re: Fehlermeldung: Microsoft Office Access-Information zur Datensatzsperrung ??



Hallo Peter,

vielen Dank für die ausführliche Antwort. Insbesondere das Workspace Object
und die Fehlerbehandlung werde ich mir zu Herzen nehmen und die ganze Sache
von Grund auf nochmals "durchforsten".

Du hast schon recht eine ausführliche Fehlerbehandlung ist sehr wichtig. Da
ich das Programm nur "übernommen" hatte, habe ich natürlich auch etwas in
dieser Richtung "geschludert". Ich muss wohl doch das ganze Programm
bezüglicher Fehlermeldungen überarbeiten.

Nochmals vielen Dank für die Anregungen und falls ich nach Abarbeitung noch
nicht weiterkomme werde ich mich nochmals melden.

Gruß Wolfgang

"Peter Götz" <gssg_nospam@xxxxxxxxxxx> schrieb im Newsbeitrag
news:ecXbgezzGHA.3656@xxxxxxxxxxxxxxxxxxxxxxx
Hallo Wolfgang,

Da Du die Frage nach

Err.Number
und
Err.Description

nicht beantwortet hast, befürchte ich, dass es in Deinem Programmcode
keine oder keine ausreichende (lückenlose) Fehlerüberwachung und
Fehlerbehandlung gibt.

Ein DB-Programm ohne lückenlose Fehlerüberwachung ist wie Autofahren
ohne Lenkrad und ohne Bremsen.

Die Taste F3 öffnet bei mir ein Formular, auf welchem auch ein
DATA-Control
für die Datenbankanbindung enthalten ist. Auszug der Eigenschaften:

Ich rate mal, die folgenden Eigenschaften gehören zu besagtem
DataControl.

.connect = Access

.Connect ist für eine Access.mdb nicht erforderlich

.DatabaseName = Pfad zur Datenbank mit Name der Access.mdb
.DefaultCursorType = 2 - Jet verwenden
.exclusive = false
.Readonly = false
.RecordsetType = 1-Dynaset
.Recorsource = Name der Tabelle in der MDB


Es gibt jedoch in einem Modul, das vorher gestartet wird, ebenfalls
eine
DAO-Anbindung an die gleiche Datenbank. Codeauszug:
----------------
If DB Is Nothing Then

Wie und wo ist DB deklariert?

Set DB = OpenDatabase(GlobalPfad & "\DATEN.MDB")

Hier vermisse ich das Workspace-Objekt

End If

If R Is Nothing Then

Wie und wo ist R deklariert?

Set R = DB.OpenRecordset("SELECT * FROM Einstellungen")
Else
R.Requery
End If

If R.RecordCount > 0 Then
R.MoveFirst
End If

Das Öffnen einer Datenbank und eines Recordsets mit DAO sollte in etwa
so aussehen:

Dim WS As DAO.Workspace
Dim DB As DAO.Database
Dim RS As DAO.Recordset
Dim FileName As String
Dim SQL As String

FileName = "D:\TestDB.mdb"
SQL = "Select * From Tabelle1"

Set WS = DAO.Workspaces(0)
Set DB = WS.OpenDatabase(FileName, False, False)
Set RS = DB.OpenRecordset(SQL, dbOpenDynaset)


--------------------

Seltsam ist, dass auch bei mir Microsoft-Office installiert ist und
keine
Fehlermeldung kommt.

Du hast doch geschrieben dass Dein Programm ein VB6-Programm ist. Also
gibt es erst mal keinen Zusammenhang zu Office. Office kann, aber muss
nicht installiert sein, wenn ein VB6-Programm via DAO auf eine *.mdb
zugreifen will.


Auch auf einem weiteren Rechner, wo kein Office
installiert ist, kommt keine Fehlermeldung.

s.oben:
erst mal gibt es da keine Zusammenhänge,
sofern Dein Programm mit einem ordentlichen Setup, welches alle
erforderlichen Laufzeitdateien enthält, auf dem jeweiligen Rechner
installiert worden ist.

Da der Fehler bei mir nicht
auftaucht, kann ich ihn leider nicht genau lokalisieren.

Mit einer vernünftigen Fehlererkennung und Fehlerbehandlung kann man
nahezu jeden auftretenden Fehler ziemlich genau lokalisieren und meist
auch sehr schnell beheben.


Der Kunde befindet
sich zur Zeit im Ausland. Ich kann daher leider nicht nachfragen ob
Err.Description und Err.Number zusätzlich überhaupt auftreten.

Du bist der Programmierer und musst also selbst wissen, ob Du eine
entsprechende Fehlererkennung in Deinem Code hast, die dann z.B. via
Messagebox eine Fehlermeldung mit Err.Number und Err.Description
ausgibt. Dein Kunde wird wohl eher wenig bis gar keine Ahnung von
Deinem Programmcode haben.


Könnte es evtl. mit "Administrator-Rechten" zu tun haben? Oder muß
ich evtl.
bei OpenDatabase noch einige Parameter "mitgeben"?

Grundsätzlich solltest Du erst mal ein einziges Workspace-Objekt
erstellen auf dem dann alle OpenDataBase-Methoden ausgeführt werden. In
Deinen Codeauszügen sehe ich überhaupt kein DAO.Workspace-Objekt.

Wenn Du unbedingt DataControls (z.B. zur Datenbindung div. Controls)
benötigst, dann öffne erst ein DataBase-Objekt, erstelle hierauf ein
Recordset-Objekt und weise dem Datacontrol dann dieses Recordset-Objekt
zu:

Set DB = WS.OpenDataBase("DBName", False, false)
Set RS = DB.OpenRecordset(SQL, dbOpenDynaset)
Set Data1.Recordset = RS

Ein weiteres Problem tritt beim Export der Daten über DAO in eine
Exell-Datei auf. Er erscheint folgende Fehlermeldung:
" Kann nicht aktualisieren. Datenbank oder Objekt sind
schreibgeschützt."

Was konkret heisst "Export der Daten über DAO"?
Wie sieht der entsprechende, relevante Code dazu aus?

Generell sagt die von Dir zitierte Fehlermeldung nicht viel und schon
gar nichts darüber aus, welche Datenbank oder welches Objekt
schreibgeschützt sind. Auch hier kann nur eine saubere
Fehlererkennung/Fehlerbehandlung eine wirklich informative
Fehlermeldung liefern.

Diese Fehlermeldung kommt seltsamerweise auf jedem Rechner vor, außer
auf
meinem?!

Dafür gibt es wahrscheinlich tausend Gründe. Ohne saubere lückenlose
Fehlererkennung in Deinem Code wirst Du die wahre Fehlerursache kaum
ermitteln können.

Nach einiger Suche im Internet konnte ich einen Hinweis darauf
finden, dass
man die Datei mit einer anderen Datei-Endekennung als .xls versehen
und dann
wieder umbenennen soll. Hiervon evtl. auch schon mal etwas gehört?

Na, das klingt schon sehr nach "Stochern im Nebel".
Um mit der Jet-Engine in eine Excel-Datei zu schreiben muss man diese
nicht umbenennen.

Wie schon erwähnt, ohne vernünftige Fehlererkennung wirst Du immer
wieder unangenehme Überraschungen mit Deinem Programm erleben.

Das Prinzip einer lückenlosen Fehlerüberwachung sieht etwa so aus:

Alle Sub/Function die ihrerseits von anderen Prozeduren aufgerufen
werden (z.b. Prozeduren in Klassenmodulen oder Modulen) erkennen einen
Fehler, erweitern Err.source um den eigenen Modul- und Prozedurnamen
und reichen den Fehler dann an die aufrufende Prozedur weiter. Das kann
auch über mehrere Prozeduren hinweg erfolgen. Die auslösende Prozedur
(z.b. Command_Click) erkennt wieder den Fehler und gibt dann eine
entsprechende Fehlermeldung aus. Hier im Beispiel wird einfach eine
MsgBox ausgegeben. In produktiven Programmen kann man an dieser Stelle
einen zentralen Errorhandler aufrufen, der neben der Ausgabe der
Fehlermeldung auch noch z.B. einen entsprechenden Fehlertext (zum
Mailen) in die Zwischenablage kopiert und evtl. auch einen Eintrag in
eine Logdatei schreibt.


' /// Code in Form-Modul
Private Sub Command1_Click()
Dim strErrMsg As String
Dim strBuffer As String

On Error GoTo Fehler
Call MySub
Ausgang:
' Aufräumcode
Exit Sub

Fehler:
With Err
strBuffer = .Source
.Source = Me.Name & "." & "Command1_Click; " & strBuffer
strErrMsg = "Fehler: " & CStr(.Number) & vbCrLf & _
"Source: " & .Source & vbCrLf & _
.Description
End With
MsgBox strErrMsg, vbExclamation
Resume Ausgang
End Sub

' /// Code in Modul/Klassenmodul:
Option Explicit
Private Const Modulname As String = "MyModul"

Public Sub MySub()
Dim strBuffer As String

On Error GoTo Fehler
Call AnySub
Exit Sub
Fehler:
With Err
strBuffer = .Source
.Source = Modulname & ".MySub(); " & strBuffer
.Raise .Number, .Source, .Description, .HelpFile, .HelpContext
End With
End Sub

Private Sub AnySub()
Dim strBuffer As String

On Error GoTo Fehler
Dim X As Integer
X = 25 / 0 ' *** löst Fehler aus
Exit Sub
Fehler:
With Err
strBuffer = .Source
.Source = Modulname & ".AnySub(); " & strBuffer
.Raise .Number, .Source, .Description, .HelpFile, .HelpContext
End With
End Sub

' /// E N T E

Mit einer solchen, konsequent angewandten Fehlerüberwachung entgeht Dir
kein Fehler und Du bekommst zu jedem Fehler eine Fehlermeldung, die Dir
neben Fehlernummer und Fehlertext in Err.Source auch noch zeigt,
welchen Weg Dein Programm vom Auslöser (Command_Click) über welche
Prozeduren bis hin zur eigentlichen Fehlerstelle (in MySub) genommen
hat.
Mit solchen Informationen ist ein evtl. auftretender Fehler meist in
wenigen Sekunden lokalisiert und die Fehlerbehebung ist in den meisten
Fällen dann auch nur eine Sache von Minuten.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)




.



Relevant Pages

  • Re: ADO-Zugriff auf Access-DB liefert Fehlermedlung. Aber warum?!?
    ... > (wie hier z.B. Connectionobjekt Cnn) zugreift. ... Fehler nicht auswirft. ... was das Programm braucht. ... aber die Fehlermeldung ist doch eindeutig ...
    (microsoft.public.de.vb.datenbank)
  • Fehler in meinem Code?
    ... Zum anderen hängt sich das Programm wohl in diesem Abschnitt auf. ... Ich finde den Fehler nicht. ... Dim Anzahl_Warnungen_aktuell As Integer = ... End Try ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Fehlermeldung: Microsoft Office Access-Information zur Datensatzsperrung ??
    ... Dim WS As DAO.Workspace ... Du hast doch geschrieben dass Dein Programm ein VB6-Programm ist. ... Messagebox eine Fehlermeldung mit Err.Number und Err.Description ... Fehler, erweitern Err.source um den eigenen Modul- und Prozedurnamen ...
    (microsoft.public.de.vb.datenbank)
  • Re: ADO-Zugriff auf Access-DB liefert Fehlermedlung. Aber warum?!?
    ... >> offenbar die Jet-Engine) wird auch mit C# nicht weniger fehlerhaft sein. ... > Fehler nicht auswirft. ... > was das Programm braucht. ... >> die Aussagekraft dieser Fehlermeldung auch erhärtet. ...
    (microsoft.public.de.vb.datenbank)
  • Re: Authentifizierungsfehler
    ... dass folgende Fehlermeldung ... > ADO-Verbindung auf, sonst passiert eigentlich nix, wo ein Fehler ... > End With ... > Ich verteile das Programm per MSI-Paket. ...
    (microsoft.public.de.vb.datenbank)