none
ODBC-Verbindung wird bei Benutzerwechsel nicht aktualisiert

    Frage

  • Hi Leute,

    folgendes Problem:

    Ich kann ganz normal eine ODBC-Verbindung zu einem SQL-Server aufbauen. Wenn ich jedoch einen Benutzerwechsel während der Laufzeit vornehmen, dann bleibt dieser User gespeichert. D.h. alle verknüpften Tabellen werden wieder mit diesem User angelegt obwohl ich diese per "DROP" aus meinem Frontend lösche.

    Was muss ich tun, damit er ordnungsgemäß meine ODBC-Verbidnung beendet und auch temporäre Daten wie User bzw. Passwort des letzten Users löscht?
    Kurz zusammengefasst:

    User A verbindet sich per ODBC an den MS SQL-Server

    Nun soll während der Laufzeit User B per ODBC an den MS SQL-Server angemeldet werden. Die Verbindung des Users A soll gelöst werden.

    Problem: Die Tabellen lösche ich aus dem Frontend und bilde einen neuen  Connectionsstring mit den Daten des Users B. Ich verbinde die Tabellen neu. Auf dem Server stelle ich aber fest (Trigger über Tabellenveränderungen), dass die ODBC-Verbindung weiterhin über User A aufgebaut wurde.


    Danke für die Hilfe!

    Dienstag, 15. November 2011 10:05

Antworten

  • Kurz und bündig: Das ist mit ODBC und damit auch mit verknüpften Tabellen nicht möglich. Microsoft Access/Jet hat ein interenes Session-Pooling. Dies kann nicht angewiesen werden, bestimmte Informationen zu löschen. Daher ist die einzige Möglichkeit ein Neustart von Access selber.

    Ich hatte selber mal folgende Lösung im Einsatz:

    Deine Anwendung wird mittels Batch (myApp.cmd) gestartet unter Benutzung von START /WAIT. Deine Applikation (Datenbank) schreibt im Fall eines Neuanmeldens ein Semaphore weg.

    Dienstag, 15. November 2011 11:07
    Moderator
  • Hallo!

    Ich nutze bei meinen Anwendungen gerne ADODB-Recordset als Datenbasis für gebundene Formulare, da ich damit immer noch den Vorteil von Access mit den gebundenen Steuerelementen nutzen kann.

    Der Mehraufwand im Vergleich zur verknüpften Tabelle entsteht durch das Binden des Recordset, das man selbst programmieren muss und nicht einfach eine Formulareigenschaft befüllen kann.

    Anm.: Clientseitiger Cursor beim Recordset nicht vergessen, sonst kann das RS nicht als Formular-Recordset verwendet werden.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Dienstag, 15. November 2011 12:50

Alle Antworten

  • Kurz und bündig: Das ist mit ODBC und damit auch mit verknüpften Tabellen nicht möglich. Microsoft Access/Jet hat ein interenes Session-Pooling. Dies kann nicht angewiesen werden, bestimmte Informationen zu löschen. Daher ist die einzige Möglichkeit ein Neustart von Access selber.

    Ich hatte selber mal folgende Lösung im Einsatz:

    Deine Anwendung wird mittels Batch (myApp.cmd) gestartet unter Benutzung von START /WAIT. Deine Applikation (Datenbank) schreibt im Fall eines Neuanmeldens ein Semaphore weg.

    Dienstag, 15. November 2011 11:07
    Moderator
  • Danke erstmal für den Hinweis!

    Ich hatte auch schon mal versucht von ODBC und verknüpften Tabellen wegzukommen. Und zwar wollte ich die Recordsource des Formulars direkt per ADO festlegen.

    Leider führte das dazu, dass dieser Zugriff immer nur schreibgeschützt funktionierte. Ich habe dabei schon etliche Kenner gesetzt und angepasst um einen Schreibzugriff zu bekommen, leider ohne Erfolg.

    Oder ist es per ADO garnicht möglich Schreibzugriff zu bekommen, wenn dieser an ein Formular gebunden wird?

    Ich setze zur Laufzeit neben der ODBC-Verbindung noch eine Verbindung direkt per ADO über

    "ADOConnObj.ConnectionString = "Driver={" & get_ODBC_SQLProvider & "};Server=SERVER;Database=DATENBANK;Uid=" & Me.tf_Username & ";Pwd=" & Me.tf_Passwort & ";""

    Es wird kein System-DSN oder Benutzer-DSN verwendet, die Verbindung erfolgt direkt über den auf dem System installierten ODBC-Treiber (hier: SQL Server Native CLient 10.0). Vielleicht liegt auch hier das Problem? Zumindest erfasst er über diesen Weg der Verbindung die korrekten Benutzerdaten.

    Thx so far!

    Dienstag, 15. November 2011 11:52
  • Nein, du kannst schon per ADO Schreibzugriff erhalten. Allerdings finde ich, dann kann man gleich auf LightSwitch oder eine andere Technik umsteigen.

    Microsoft Access entfaltet nun mal seine ganzen Möglichkeiten erst, wenn du mit (verknüpften) Tabellen arbeitest. Daher habe ich damals die Anforderung des Benutzerwechsels eben so gelöst.

    Dienstag, 15. November 2011 12:18
    Moderator
  • Ja, sicherlich hast du Recht!

    Werde aber auf meinem Mittelweg bleiben, weil ich gespeicherte Prozeduren verwende und deswegen diesen zusätzlichen Weg über ADO brauche.

    Eine Umprogrammierung in Lightswitch ist zur Zeit nicht möglich, da einfach die Zeit fehlt. Deswegen wäre ich dann eben diesen eher suboptimalen Weg gegangen. Brauche das bzgl. des Recordsets auch nur für ein einziges Formular, da hier Eingaben vorgenommen werden. Die restlichen Formulare dienen nur zur Anzeige und Auswertung. Aber wie geschrieben hab ich das nur Read-Only hinbekommen.

    Gruß

    Johannes

    Dienstag, 15. November 2011 12:34
  • Hallo!

    Ich nutze bei meinen Anwendungen gerne ADODB-Recordset als Datenbasis für gebundene Formulare, da ich damit immer noch den Vorteil von Access mit den gebundenen Steuerelementen nutzen kann.

    Der Mehraufwand im Vergleich zur verknüpften Tabelle entsteht durch das Binden des Recordset, das man selbst programmieren muss und nicht einfach eine Formulareigenschaft befüllen kann.

    Anm.: Clientseitiger Cursor beim Recordset nicht vergessen, sonst kann das RS nicht als Formular-Recordset verwendet werden.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Dienstag, 15. November 2011 12:50