none
Connection-Problem Access2003 (auf SQL2005)

    Frage

  • Wir entwickeln seit mehreren Jahren unser Frontend (XP+W7) in Access2003 (VBA) zur Anbindung an SQL-Server 2005. Seit einigen Wochen kann ich aus dem Projekt keine lauffähige ADE mehr erzeugen. Nicht lauffähig im Sinne von fehlerhafter Connection.
    An den Basiseinstellungen zur Verbindung wurde nichts geändert. Umso verwunderlich ist es, dass sich auf einmal die Verbindung zum SQL nicht problemlos aufbauen läßt.
    Was passiert im Hintergrund:
    Da nicht alle User, die die Datenbank nutzen sollen, als Netzwerkuser angelegt sind, wurde eine gemischte Anmeldung verwendet. Jeder User ist mit Passwort explizit angelegt. Die Basisverbindung ist eine allgemeine Anmeldung. Dann erhält der User eine Login-Maske, in der der User Namen und Passwort zur Anmeldung angibt.
    Die Application.CurrentProject.Connection wird geschlossen und eine neue Verbindung mit dem jeweiligen User wird geöffnet. Das funktioniert soweit problemlos (scheinbar).
    Beim Abruf weiterer Daten aus der Datenbank kommt es dann zu Problemen; zwei verschiedene Beispielcodes:

    Sub LeseDaten(ByVal myPK as long)
      Dim cn as ADODB.Connection, rs as New ADODB.RecordSource, sql as string
      set cn = CurrentProject.Connection
      sql = "select * from tblDaten where PK=" & myPK
      rs.Open sql, cn, adOpenDynamic, adLockOptimistic
      '... do something
      dim f as string
      f=GetParameter(27)
      '... do something
      rs.Close
      cn.Close
      set rs = Nothing
      set cn = Nothing
     
    End Sub
    --> Fehler bei 'set cn'

    Sub LeseDaten(ByVal myPK as long)
      Dim cn as New ADODB.Connection, rs as New ADODB.RecordSource, sql as string
      cn.ConnectionString = Global_ConnectionString           'wird beim Start korrekt erzeugt 
      'cn.ConnectionString = CurrentProject.Connection.BaseConnectionString         'testweise benutzt, auch ohne Erfolg
      cn.Open
      sql = "select * from tblDaten where PK=" & myPK
      rs.Open sql, cn, adOpenDynamic, adLockOptimistic
      '... do something
      dim f as string
      f=GetParameter(27)
      '... do something
      rs.Close
      cn.Close
      set rs = Nothing
      set cn = Nothing
     
    End Sub
    --> Fehler bei 'cn='

    Function GetParameter(ByVal pid as long)
      Dim v as string
      Dim cn as ADODB.Connection, rs as New ADODB.RecordSource, sql as string
      set cn = CurrentProject.Connection
      sql = "select * from tblParameter where PK=" & pid
      rs.Open sql, cn, adOpenForwardOnly, adLockReadOnly
      if rs.RecordCount=1 then
        v=rs.Fields("Wert")
      else
        v=""
      endif
      rs.Close
      cn.Close
      set rs = Nothing
      set cn = Nothing

      GetParameter=v
    End Function

    Folgende Fehlermeldungen treten auf (eventuell sogar System abhängig XP,Windows7):
    Fall 1: Typen unverträglich
    Fall 2: Automatisierungsfehler

    Teilweise werden auch mehrere Verbindungen gleichzeitig benötigt, was vorher auch kein Problem darstellte. Der Fehler taucht auch nicht immer an der gleichen Stelle auf. Auch zwischen XP und W7-Systemen scheint es Unterschiede zu geben. Kann es sein, das es beim MSDN-SQL-Server irgendwelche Einschränkungen gibt. Ich teste mit 30 Frontends auf dergleichen. Die Produktivumgebung ist dann identisch. Das Frontend ist als Projekt 50MB groß, als ADE dann ca. 17 MB.
    Irgendwie steht ich seit Montag hier auf der Stelle und weiß nicht im geringsten, wie ich dem Problem beikommen kann.

    Gab es in letzter Zeit irgendwelche Microsoft-Updates, die mir hier ein quasi ein Bein stellen ?
    Weiß jemand, woran dies liegen kann, oder wie man codetechnisch besser verfahren sollte ?'

    Danke vorab, Mario Koch

    Donnerstag, 19. Mai 2011 06:43

Antworten

  • Hallo Mario,

    wo ich Windows 7 und ADO + Typen unverträglich lese; ist zufällig das Service Pack 1 für W7 installiert worden?

    Siehe z.B.: Massive Probleme mit ADO auf Windows 7 SP1


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 19. Mai 2011 07:14
  • hi Mario,

    Folgende Fehlermeldungen treten auf (eventuell sogar System abhängig XP,Windows7):
    Fall 1: Typen unverträglich
    Fall 2: Automatisierungsfehler

    Die Meldungen bedeuten im Normalfall immer, das die Registierung der benötigten Bibliotheken/Komponenten nicht mehr korrekt ist. Das ist erstmal nicht systemabhängig.

    Ich würde erstmal ein sfc repair laufen lassen.

    Du verwendest ein Objekt ADODB.RecordSource. Davon hab ich noch nie gehört. Ist da ein spezielles Paket nicht installiert worden.

    btw, außerdem verwendest du den unter VBA "fehlerbehafteten" impliziten, Dim As New Konstruktor. Dieser hat unter VBA ein anderes Verhalten als unter VB und kann daher Fehler maskieren. Zur Demonstration:

    Public Sub TestDimAsNew()
       Dim cn As New ADODB.Connection
       If Not cn Is Nothing Then
        MsgBox "Yeah!
      End If
       Set cn = Nothing
       If Not cn Is Nothing Then
        MsgBox "Hae?
      End If
    
    End Sub

    Das ganze in ein Standardmodul kopieren und ausführen. Ergo unter VBA immer explizit arbeiten:

    [vbnet]
    Public Sub TestDimAsNew()
       Dim cn As ADODB.Connection
       Set cn = New ADODB.Connection
       If Not cn Is Nothing Then
        MsgBox "Yeah!
      End If
       Set cn = Nothing
       If Not cn Is Nothing Then
        MsgBox "Hae?
      End If
    
    End Sub

    Microsoft MVP Office Access
    https://mvp.support.microsoft.com/profile/Stefan.Hoffmann
    Donnerstag, 19. Mai 2011 07:54
    Moderator
  • Hallo Mario, Olaf,

    ich bin hier nur durch Zufall reingestolpert.

    Nach dem Lesen des MSDN-Threads und vielem Kopfschütteln ...
    (die hilfreichsten Antworten liefert dort Pak-Ming Cheung, wer sich den Noise ersparen will)

    Das betrifft alle ADO Anwendungen, die auf Windows 7 SP1 entwickelt werden
    und auf ein früheres Betriebssystem (oder Windows 7 ohne SP1) verteilt werden.

    Derzeitiger Stand ist
    An ADO application does not run on down-level operating systems after you recompile it
    on a computer that is running Windows 7 SP 1 or Windows Server 2008 R2 SP 1 or that has KB983246 installed

    Vermeiden könnte man den Fehler ansonsten nur wenn man Late Binding verwendet,
    also CreateObject("ADODB.Connection")
    Und für eine Access MDE/ACCDE gilt dies nicht, siehe Hinweis im KB Artikel bei Method1:

    Method 2 [late binding] does not apply VBA to applications.
    The compiled Access file (*.mde or *.accde) has to read the downloaded typelib (.tlb) file at runtime,
    and it is unlikely that the downloaded .tlb file will be present on end-user computers.

    Gruß Elmar


    Donnerstag, 19. Mai 2011 09:37

Alle Antworten

  • Hallo Mario,

    wo ich Windows 7 und ADO + Typen unverträglich lese; ist zufällig das Service Pack 1 für W7 installiert worden?

    Siehe z.B.: Massive Probleme mit ADO auf Windows 7 SP1


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 19. Mai 2011 07:14
  • hi Mario,

    Folgende Fehlermeldungen treten auf (eventuell sogar System abhängig XP,Windows7):
    Fall 1: Typen unverträglich
    Fall 2: Automatisierungsfehler

    Die Meldungen bedeuten im Normalfall immer, das die Registierung der benötigten Bibliotheken/Komponenten nicht mehr korrekt ist. Das ist erstmal nicht systemabhängig.

    Ich würde erstmal ein sfc repair laufen lassen.

    Du verwendest ein Objekt ADODB.RecordSource. Davon hab ich noch nie gehört. Ist da ein spezielles Paket nicht installiert worden.

    btw, außerdem verwendest du den unter VBA "fehlerbehafteten" impliziten, Dim As New Konstruktor. Dieser hat unter VBA ein anderes Verhalten als unter VB und kann daher Fehler maskieren. Zur Demonstration:

    Public Sub TestDimAsNew()
       Dim cn As New ADODB.Connection
       If Not cn Is Nothing Then
        MsgBox "Yeah!
      End If
       Set cn = Nothing
       If Not cn Is Nothing Then
        MsgBox "Hae?
      End If
    
    End Sub

    Das ganze in ein Standardmodul kopieren und ausführen. Ergo unter VBA immer explizit arbeiten:

    [vbnet]
    Public Sub TestDimAsNew()
       Dim cn As ADODB.Connection
       Set cn = New ADODB.Connection
       If Not cn Is Nothing Then
        MsgBox "Yeah!
      End If
       Set cn = Nothing
       If Not cn Is Nothing Then
        MsgBox "Hae?
      End If
    
    End Sub

    Microsoft MVP Office Access
    https://mvp.support.microsoft.com/profile/Stefan.Hoffmann
    Donnerstag, 19. Mai 2011 07:54
    Moderator
  • Hallo Olaf,

    ich habe weiter recherchiert. Offenbar hast Du mich auf den richtigen Weg gebracht. Mit dem SP für W7 wurde die ADO-Schnittstelle geändert. Da mein Entwicklungssystem darauf aufsetzt, kommt es mit der Erzeugung der ADE offenbar zum Verteilen der fehlerhaften Interfaces. Zumindest gibt es diesbezüglich reichlich Infos im Netz.
    Da der Fehler sowohl auf XP als auch auf W7-Clients auftaucht, denke ich, das dies ein Ansatzpunkt ist.

    Ich werde jetzt meine Entwicklungsumgebung auf einem XP-Rechner aufsetzen und das ganze nochmal durchführen und die ADE erzeugen. Ich gebe dann später hier ein Feedback.

    Donnerstag, 19. Mai 2011 08:06
  • Hallo Mario,

    was mir bisher bekannt ist, gibt es dann Probleme, wenn man auf Win7 x64 Bit + SP1 entwickelt und die ADE dann auf Nicht-Win7 x64 Bit + SP1 nutzten will.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 19. Mai 2011 08:12
  • Sorry, das war ein Schreibfehler von mir.

    ADODB.RecordSource  -->  ADODB.RecordSet

    Donnerstag, 19. Mai 2011 08:19
  • Meinst Du dies mit dem 'New' generell, also auch für das ADODB.RecordSet oder nur für die Connection ?
    Donnerstag, 19. Mai 2011 09:27
  • Hallo Mario, Olaf,

    ich bin hier nur durch Zufall reingestolpert.

    Nach dem Lesen des MSDN-Threads und vielem Kopfschütteln ...
    (die hilfreichsten Antworten liefert dort Pak-Ming Cheung, wer sich den Noise ersparen will)

    Das betrifft alle ADO Anwendungen, die auf Windows 7 SP1 entwickelt werden
    und auf ein früheres Betriebssystem (oder Windows 7 ohne SP1) verteilt werden.

    Derzeitiger Stand ist
    An ADO application does not run on down-level operating systems after you recompile it
    on a computer that is running Windows 7 SP 1 or Windows Server 2008 R2 SP 1 or that has KB983246 installed

    Vermeiden könnte man den Fehler ansonsten nur wenn man Late Binding verwendet,
    also CreateObject("ADODB.Connection")
    Und für eine Access MDE/ACCDE gilt dies nicht, siehe Hinweis im KB Artikel bei Method1:

    Method 2 [late binding] does not apply VBA to applications.
    The compiled Access file (*.mde or *.accde) has to read the downloaded typelib (.tlb) file at runtime,
    and it is unlikely that the downloaded .tlb file will be present on end-user computers.

    Gruß Elmar


    Donnerstag, 19. Mai 2011 09:37
  • Hallo,

    m.koch wrote:

    Meinst Du dies mit dem 'New' generell, also auch für das ADODB.RecordSet
    oder nur für die Connection ?

    Fuer das Recordset. Die Connection hast du ja richtigerweise ohne New
    deklariert.

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    Donnerstag, 19. Mai 2011 21:55
    Moderator
  • Servus,

    Du solltest es in VBA generell, also niemals mit der Deklaration benutzen.


    Microsoft MVP Office Access
    https://mvp.support.microsoft.com/profile/Stefan.Hoffmann
    Freitag, 20. Mai 2011 08:10
    Moderator