Re: Verbindungsversuch zu einer Datenbank

• Previous message: Peter Götz: "Re: doppelten zugriff auf mdb"
• In reply to: Fred Keding: "Verbindungsversuch zu einer Datenbank"
• Next in thread: Fred Keding: "Re: Verbindungsversuch zu einer Datenbank"
• Reply: Fred Keding: "Re: Verbindungsversuch zu einer Datenbank"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 2 Apr 2004 16:47:45 +0200

Hallo Fred,

    vergiss dieses überflüssige DataEnvironment und erstelle Deine
ADO-Objekte Connection, Command u. Recordset per konkretem Code. Das
Dataenvironment macht auch nichts anderes, hindert Dich aber daran zu sehen
und zu verstehen, was diese Objekte eigentlich tun.

Die Verbindung zu Deiner DB stellst Du so her:

    Option Explicit
    Private WithEvents mCnn as ADODB.Connection

    Private Sub CnnOpen(DBFileName as string, DBPwd ad String)
        Set mCnn = New ADODB.Connection

        ' *** Connection öffnen
        With mCnn
            .Provider = "Microsoft.Jet.OLEDB.4.0"
            .Properties("Data Source").Value = DBFileName

            If Len(DBPwd) Then
                .Properties("Jet OLEDB:Database Password").Value = DBPwd
            End If

            .CursorLocation = adUseClient
            .Mode = adModeShareDenyNone

            .Open
        End With
    End Sub

Jetzt kannst Du an die Sub CnnOpen jeden beliebigen Pfadnamen und ein
Datenbankkennwort für Deine *.mdb übergeben.

> ich habe ein Problem mit einer Datenbankanbindung.
> Folgender Code ist aus einem Beispiel, welches im
> Buch "Visual Basic 6" von M. Kofler abgebildet ist.
>
> Public Sub Form_Load()
>
> Dim oText1 As TextBox
> Dim oText2 As TextBox
>
> On Error GoTo OpenErr
>
> ' Verbindung zur Datenbank öffnen
> Set adoPrimaryRS1 = DataEnvironment1.rsCommand1
> adoPrimaryRS1.Open
> CursorType:=adOpenStatic, LockType:=adLockOptimistic

Ein Recordset öffnet man so:

    Option Explicit
    Private WithEvents mRS As ADODB.Recordset

    Private Sub OpenRS(SQL as String)
        Set mRS = New ADODB.Recordset

        ' *** Recordset öffnen
        With mRS
            Set .ActiveConnection = mCnn
            .Source = SQL
            .CursorLocation = adUseClient
            .CursorType = adOpenStatic
            .LockType = adLockOptimistic

            .Open
        End With
    End Sub

>
> Set adoPrimaryRS2 = DataEnvironment1.rsCommand2
> adoPrimaryRS2.Open
> CursorType:=adOpenStatic, LockType:=adLockOptimistic
>
> If adoPrimaryRS1.State = 1 Then connectionOK = True

Das ist eigentlich unsinnig.
Recordset.State sagt nicht aus ob die Connection in Ordnung ist.
Man kann ein Recordset öffnen, es dann per

    Set RS.ActiveConnection = Nothing

vom Connectionobjekt trennen und dann die Connection schliessen

    Cnn.Close

RS.State hat jetzt immer noch den Wert adStateOpen (1), obwohl die
Connection keineswegs mehr geöffnet ist.

So überprüfst Du, ob Dein Recordset existier, geöffnet ist und auf einem
gültigen Datensatz steht:

    Select case True
        case mRS is Nothing
        case (mRS.State and adStateOpen) = adStateOpen
        case mRS.BOF or mRS.EOF
        case else
            ' Juchhuuuu... das Recordset existiert, _
              ist geöffnet und _
              steht auf einem gültigen Datensatz
    End Select

>
> ' Textfelder an Datenprovider binden
> For Each oText1 In Me.txtFields1
> Set oText1.DataSource = adoPrimaryRS1
> Next
> For Each oText2 In Me.txtFields2
> Set oText2.DataSource = adoPrimaryRS2
> Next

Wenn Du ein vernünftig und vor allem stabil laufendes Datenbankprogramm
haben willst, dann verzichte auf gebundene Controls. Damit verlierst
weitgehend die Kontrolle über die Abläufe bei Deinen ADO-Objekten und gerade
bei einem Mehrbenutzerbetrieb wird eine vernünftige Fehler- und
Konfliktbehandlung nahezu unmöglich.

>
> Exit Sub
>
> OpenErr:
> MsgBox Err.Description

Um bei DB-Fehlern die eigentlich Fehlerursache zu erkennen musst Du in den
meisten Fällen nicht nur das VB-Err-Objekt sondern die
ADODB.Connection.Errors-Auflistung untersuchen. Erst darin findest Du meist
die wirklichen, detaillierten Fehlerinformationen.

>
> End Sub
>
> "DataEnvironment1.rsCommand1" und "-2" ist die Verbindung
> zu einer bestehenden .mdb-Datenbank.

Ein Command ist keine Verbindung zu einer DB.
Die Verbindung zur DB wird über das Connection-Objekt hergestellt.
Ein Commandobjekt führt Befehle über die vom Connection-Objekt hergestellte
Verbindung aus.

> Der Code funktioniert einwandfrei, solange ich die
> Datenbankdatei an der voreingestellten Stelle belasse.

Genau das ist das Problem mit diesen Gimmicks DataEnvironment und ADODC.
Du kopierst irgendwelchen vorgestanzten Code ab, der so lala funktioniert.
Aber warum er funktioniert und warum in einem anderen Fall eben nicht, wirst
Du mit einem DataEnvironment vermutlich nie verstehen.

> Wenn ich diese Datei vor dem Start meines Programms
> verlagere (Ich möchte damit simulieren, dass z.B. keine
> Verbindung aufgebaut werden kann, Netzwerk down o.ä.),
> kommt eine Abfrage mit dem Titel "Geben Sie bitte MS JET
> OLE-DB-Initialisierungsinformationen ein". Dieses Fenster
> stört mich, da ich dem Bediener eigentlich mit einer
> selbstprojektierten MsgBox den fehlgeschlagenen
> Verbindungsversuch mitteilen will. Weiß jemand, wie ich
> das Initialisierungsfenster unterdrücken kann ?

1) Kein DataEnvironment benutzen
2) Kein DataControl (ADODC) benutzen
3) Connection-, Recordset- u. Command-Objekte per konkretem Code erzeugen

Unter

    www.gssg.de -> VB-Tips -> Datenbank -> "ADO DemoMU 2002"

findest Du ein Programm welches für den Mehrbenutzerbetrieb auf eine *.mdb
konzipiert ist.

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

• Previous message: Peter Götz: "Re: doppelten zugriff auf mdb"
• In reply to: Fred Keding: "Verbindungsversuch zu einer Datenbank"
• Next in thread: Fred Keding: "Re: Verbindungsversuch zu einer Datenbank"
• Reply: Fred Keding: "Re: Verbindungsversuch zu einer Datenbank"
• Messages sorted by: [ date ] [ thread ]