none
Unter Windows 7 kann ich in Visual Studio nicht mehr auf Access-Datenbanken zugreifen. RRS feed

  • Frage

  • Ich habe eine C#-Anwendung in Visual Studio 2008 auf Win XP (32 Bit) geschrieben. Diese Anwendung greift auf einige Tabellen und Abfragen einer Access-Datenbank zu. Seit Jahren kein Problem.

    Jetzt habe ich ein Notebook mit Windows 7 gekauft und diese Anwendung dort eingerichtet und getestet. Ich erhalte eine Fehlermeldung beim Datenbank-Zugriff, in der sich der ODBC-Treiber mit einer mir unverständlichen Meldung beschwert. Ich habe daraufhin Visual Studio auf dem Rechner installiert und versucht zu debuggen. Gleiche unverständliche Meldung.

    Im nächsten Versuch habe ich die Datenbankschnittstelle neu eingerichtet und diesmal über Jet OLEDB direkt auf die Access-DB zugegriffen. In der Datenvorschau des Datasets geht noch alles (ich kann also die Tabelle mit korrekten Einträgen sehen). Aber sobald ich die Anwendung starte (auch im Debug-Mode), springt der Ablauf ab der .Fill-Methode einfach aus dem Unterprogramm ohne jede Meldung. Also: der komplette Code nach der .Fill-Methode wird ignoriert und ich erhalte keine Fehlermeldung (aber natürlich ein Fehlverhalten).

    Im folgenden Beispielcode passiert also folgendes: Im label1 kann ich sehen, daß der Text auf "Start ..." geändert wird. Dann passiert nichts (keine Fehlermeldung aber sehr wohl weitere Programm-Bedienbarkeit, als sei nichts gewesen). Insbesondere erscheint auch der Textwechsel in label1 zu "...done" nicht.

            private void Form1_Load(object sender, EventArgs e)
            {
                label1.Text = "Start ...";
                // TODO: Diese Codezeile lädt Daten in die Tabelle "testDataSet.Tabelle1". Sie können sie bei Bedarf verschieben oder entfernen.
                this.tabelle1TableAdapter.Fill(this.testDataSet.Tabelle1);
                label1.Text = "...done";
            }

    Ich finde in der Hilfe keinen weiteren Rat mehr. Wer kann mir helfen?

     

    Samstag, 19. Februar 2011 16:11

Antworten

  • Hallo Werner

    nur zur Sicherheit, ist es etwa ein 64-Bit Windows 7?
    Falls ja, dann könnte die Zielplattform in deinem Projekt (wg VS2008 default) noch auf 'AnyCPU' stehen, was bewirkt dass deine App jetzt als 64-Bit läuft!
    Stelle die Zielplattform mal auf x86 (fix 32-Bit).
    Oder installiere die 64-Bit Acess/Jet OLEDB Treiber.
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D
     (ggf Connection String anpassen, OLDB etwa "Microsoft.ACE.OLEDB.12.0")

    • Als Antwort vorgeschlagen Marcel RomaModerator Samstag, 19. Februar 2011 17:26
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:15
  • Zunächst ein Hinweis: Auch wenn Dir die Fehlermeldung des ODBC-Treibers unverständlich erscheint könnte es hilfreich sein diese hier zu posten, da evtl. andere, die Dir helfen möchten, damit etwas anfangen können.

    Da Du die Fehlermeldung nicht gepostet hast kann ich nur raten: Ich nehme an, dass Deine Anwendung als 64bit-Prozess läuft und über einen 32bit-Datenbanktreiber versucht auf die Datenbank zuzugreifen. Da das Laden von 32bit-Dlls in 64bit-Prozessen nicht unterstützt wird kommt es dann zu dem von Dir beschriebenen Fehler. Versuch mal, Deine Anwendung explizit für x86 zu kompilieren.


    Andreas Miceli - Author of the Advanced Admin Console AddIn
    • Als Antwort vorgeschlagen Marcel RomaModerator Samstag, 19. Februar 2011 17:26
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:17
  • 64-Bit Access/Jet OLEDB-Treiber finde ich noch interessant. Wie kann ich diesen treiber installieren?

    Werner, bereits nachgetragen
    die 64-Bit Acess/Jet OLEDB Treiber:
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D
     (ggf Connection String anpassen, OLDB etwa "Microsoft.ACE.OLEDB.12.0")

    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:25
  • Danke, hat geklappt.

    Vielen Dank für die kompetente Hilfe.


    Werner Binsmaier
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 16:42
    Samstag, 19. Februar 2011 16:42
  • Hallo Werner,

    wichtig ist immer die "Zielpattform", nicht unbedingt, was als Active da steht, denn das wird erst dadurch definiert.
    Das ist leider oft eine Quelle von Mißverständnissen.

    Also zum Beispiel: Projekt/Eigenschaften/Erstellen/Zielplattform auf x86 stellen.

    Oder suche auch direkt in der **.csproj nach "<PlatformTarget>", da sollte dann Deine gewünschte Architektur stehen.


    ciao Frank

    • Als Antwort markiert Werner B Sonntag, 20. Februar 2011 20:15
    Sonntag, 20. Februar 2011 10:16

Alle Antworten

  • Hallo Werner

    nur zur Sicherheit, ist es etwa ein 64-Bit Windows 7?
    Falls ja, dann könnte die Zielplattform in deinem Projekt (wg VS2008 default) noch auf 'AnyCPU' stehen, was bewirkt dass deine App jetzt als 64-Bit läuft!
    Stelle die Zielplattform mal auf x86 (fix 32-Bit).
    Oder installiere die 64-Bit Acess/Jet OLEDB Treiber.
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D
     (ggf Connection String anpassen, OLDB etwa "Microsoft.ACE.OLEDB.12.0")

    • Als Antwort vorgeschlagen Marcel RomaModerator Samstag, 19. Februar 2011 17:26
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:15
  • Zunächst ein Hinweis: Auch wenn Dir die Fehlermeldung des ODBC-Treibers unverständlich erscheint könnte es hilfreich sein diese hier zu posten, da evtl. andere, die Dir helfen möchten, damit etwas anfangen können.

    Da Du die Fehlermeldung nicht gepostet hast kann ich nur raten: Ich nehme an, dass Deine Anwendung als 64bit-Prozess läuft und über einen 32bit-Datenbanktreiber versucht auf die Datenbank zuzugreifen. Da das Laden von 32bit-Dlls in 64bit-Prozessen nicht unterstützt wird kommt es dann zu dem von Dir beschriebenen Fehler. Versuch mal, Deine Anwendung explizit für x86 zu kompilieren.


    Andreas Miceli - Author of the Advanced Admin Console AddIn
    • Als Antwort vorgeschlagen Marcel RomaModerator Samstag, 19. Februar 2011 17:26
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:17
  • Hallo Andreas, hallo Thomas,

    vielen Dank, nachdem ich von AnyCPU auf x86 geändert habe, hat alles funktioniert.

    Aber Thomas, Dein Hinweis auf den 64-Bit Access/Jet OLEDB-Treiber finde ich noch interessant. Wie kann ich diesen treiber installieren?

     


    Werner Binsmaier
    Samstag, 19. Februar 2011 16:24
  • 64-Bit Access/Jet OLEDB-Treiber finde ich noch interessant. Wie kann ich diesen treiber installieren?

    Werner, bereits nachgetragen
    die 64-Bit Acess/Jet OLEDB Treiber:
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D
     (ggf Connection String anpassen, OLDB etwa "Microsoft.ACE.OLEDB.12.0")

    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 19:11
    Samstag, 19. Februar 2011 16:25
  • Danke, hat geklappt.

    Vielen Dank für die kompetente Hilfe.


    Werner Binsmaier
    • Als Antwort markiert Werner B Samstag, 19. Februar 2011 16:42
    Samstag, 19. Februar 2011 16:42
  • Hallo Werner,

    Bitte markiere die Beiträge von Thomas und Andreas als Antwort. Diese enthalten die Lösung Deines Problems. Ich habe die Beiträge bereits als Antwort vorgeschlagen.

    Gruss
    Marcel

    Samstag, 19. Februar 2011 17:28
    Moderator
  • Tja, zu früh  gefreut ...

    Im Debug-Mode hat die Applikation getan. Aber als ich sie veröffentlicht habe, mußte ich feststellen, daß die Anwendung wieder meckert "Microsoft.Jet.OLEDB 4.0 auf diesem Computer nicht als Provider registriert".

    Ich habe im Netz jede Menge Antworten zu diesem Thema gefunden, aber alle verweisen doch nur auf die Kompilerung für x86. Ich habe nochmal geprüft, ob ich wirklich umgestellt habe auch für Release-Mode. Habe ich !

    Was soll ich tun?


    Werner Binsmaier
    Samstag, 19. Februar 2011 19:16
  • Werner,
    dann machst du etwas falsch mit dem Release-Build.
      (man kann auch am falschen Ort eine x86-'Einstellung' umschalten, weil zT leider gleich benannt)
    Auch scheint es mit Studio Express unter dessen amateuerhaften Default-Einstellungen und ClickOnce nochmals schwieriger:
    http://stackoverflow.com/questions/1142701/why-does-vb-net-jet-4-0-app-crash-if-office-not-installed

    Und was bedeutet dein ''veröffentlicht'? etwa Installation auf anderem PC  (ohne entspr Treiber)?
    Samstag, 19. Februar 2011 19:31
  • Hallo Werner,

    Im Debug-Mode hat die Applikation getan. Aber als ich sie veröffentlicht habe, mußte ich feststellen, daß die Anwendung wieder meckert "Microsoft.Jet.OLEDB 4.0 auf diesem Computer nicht als Provider registriert".

    das ist nicht zufällig eine Webanwendung (ASP.NET)? Falls doch, musst Du auf dem IIS noch dafür sorgen, dass die Anwendung als 32 Bit Applikation ausgeführt wird.

    Bei IIS 7 kann man das pro Application Pool machen, bei IIS 6 leider nur für den gesamten IIS komplett.

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Samstag, 19. Februar 2011 20:02
    Moderator
  • Thomas,

    ich arbeite unter Visual Studio 2008 .Net mit C#. "Veröffentlichen" meint nach Microsoft-Terminologie das Deployment der Applikation, also die Erzeugung der lauffähigen Applikation mit den nötigen DLLs und Umgebungsdateien (*.manifest, *.xxx).

    Ich habe alle mir bekannten Settings geprüft und an den jeweiligen Stellen x86 als Zielplattform angegeben. Jetzt bin ich am Ende meiner Möglichkeiten.

    Any idea?


    Werner Binsmaier
    Samstag, 19. Februar 2011 20:03
  • Hallo Stefan,

    nein, das ist keine Web-Anwendung (ASP.Net). Aber trotzdem Danke für den Hilfeversuch.


    Werner Binsmaier
    Samstag, 19. Februar 2011 20:13
  • Hallo Werner,

    ich arbeite unter Visual Studio 2008 .Net mit C#. "Veröffentlichen" meint nach Microsoft-Terminologie das Deployment der Applikation, also die Erzeugung der lauffähigen Applikation mit den nötigen DLLs und Umgebungsdateien (*.manifest, *.xxx).

    ist das derselbe Rechner, auf dem die veröffentlichte Anwendung gestartet werden soll? Falls nicht, welches Zielsystem hast Du da?

    Schau bitte auch mal nach dem Starten (Fehlermeldung ggfs. erstmal einfach stehen lassen), ob im TaskManager der Prozess als "Prozessname.exe *32" erscheint. Falls nicht (und falls das Zielsystem ein 64 Bit OS ist), läuft der Prozess eben nicht als 32 Bit Anwendung.

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Samstag, 19. Februar 2011 20:36
    Moderator
  • Hallo Stefan, wie Du erwartet hast, startet das Programm nicht als 32-Bit-Anwendung. Im Taskmanager ist der Prozess nicht mit *32 gekennzeichnet, sehr wohl einige andere, sodaß ich das als sichers Zeichen verstehe. Nun haben wir das alle mittlerweile diagnostiziert und hiermit sicher bestätigt. Danke für den Trick, den ich bisher nicht kannte (ich bin Win7-Neuling). Zusammengefasst: 1. ich habe versucht, alle Einstellungen in Visual Studio in diesem C#-WindowsForms-Projekt von "AnyCPU" auf "x86" umzustellen. 2. Visual Studio zeigt beim Wiederanzeigen diverser Masken beim "Veröffentlichen" und "Projekt erstellen" auch "x86" oder auch "Aktiv (x86)" an. 3. Innerhalb Visual Studio kann ich das Projekt im Debug-Mode auf dem Win7-Rechner laufen lassen und es tut. 4. Nach Veröffentlichung kann ich das Programm vom Explorer aus auf dem Win7-Rechner starten und es tut nicht. 5. Auf dem WinXP-Rechner geht es (natürlich) immer (32-Bit). Welchen Fehler mache ich?
    Werner Binsmaier
    Sonntag, 20. Februar 2011 09:37
  • Hallo Werner,

    wichtig ist immer die "Zielpattform", nicht unbedingt, was als Active da steht, denn das wird erst dadurch definiert.
    Das ist leider oft eine Quelle von Mißverständnissen.

    Also zum Beispiel: Projekt/Eigenschaften/Erstellen/Zielplattform auf x86 stellen.

    Oder suche auch direkt in der **.csproj nach "<PlatformTarget>", da sollte dann Deine gewünschte Architektur stehen.


    ciao Frank

    • Als Antwort markiert Werner B Sonntag, 20. Februar 2011 20:15
    Sonntag, 20. Februar 2011 10:16
  • Hallo Frank,

    Dein Hinweis hat mich letztlich auf die richtige Spur gebracht. Die Datei *.csproj war zwar ok, aber ich habe gesehen, daß dort ein Ausgabeverzeichnis eingestellt war, das ich nicht explizit angegeben hatte. Ich habe dann in Visual Studio in der Maske Projekt->Eigenschaften->Erstellen diesen Pfad "Ausgabepfad: bin\x86\Debug" anstelle des üblichen "Ausgabepfad: bin\Debug" wieder gefunden. Er wurde offensichtlich als Default-Pfad eingestellt als ich auf x86 umgestellt hatte.

    Visual Studio erzeugt beim Erstellen des Projektes (zum anschließenden Debugging) eine lauffähige *.exe, und zwar auch im richtigen verzeichnis. Jedoch beim Veröffentlichen wird offensichtlich falsch kopiert. Ich habe den Fehler bisher noch nicht ganz überblickt. Wenn ich jedoch die *.exe aus dem richtigen Verzeichnis über die veröffentlichte *.exe im endgültigen Arbeitsverzeichnis einfach drüberkopiere, dann geht alles. Wie gesagt, ich habe das System noch nicht verstanden, macht jetzt der Linker einen Fehler beim Erzeugen der *.exe oder ist es doch nur der Veröffentlicher, der die falsche Datei kopiert? Im Moment bin ich noch verwirrt. Ich habe aber eine Lösung (momentan noch manueller Kopieraufwand) und werde mir morgen mit kühlem Kopf nochmal den Fehler genauer ansehen.

    Hiermit ist für mich dieser Fall ausreichend gut beantwortet. Vielen, vielen Dank an alle Helfer !!


    Werner Binsmaier
    Sonntag, 20. Februar 2011 20:28