SQL-Datenbank portiert auf anderen PC: Fehler-Message bei Ausführung von Connection

Question

Hallo zusammen,

ich habe via Scripts meien Datenbank auf einen anderen PC portiert. Im SSMS wird dort alles ohne Probleme verbunden und angezeigt.

Wenn ich aber meine seit Jahren mit dieser Datenbank laufende Application starte, an deren Anfang zuerst die Connection zur Datenbank aufgebaut wird, erhalte ich einen Fehler, den ich nicht interpretieren kann.
Hier die Meldung:
************** Ausnahmetext **************
System.TypeInitializationException: Der Typeninitialisierer für "System.Data.SqlClient.SqlConnection" hat eine Ausnahme verursacht. ---> System.InvalidOperationException: Failed to read the configuration section for enclave providers. Make sure the section is correctly formatted in your application configuration file. Error Message: Das Konfigurationssystem konnte nicht initialisiert werden. ---> System.Configuration.ConfigurationErrorsException: Das Konfigurationssystem konnte nicht initialisiert werden. ---> System.Configuration.ConfigurationErrorsException: Unbekannter Konfigurationsabschnitt "userSettings". (C:\Users\dietr\AppData\Local\BingMapsRoutes\BingMapsRoutes.exe_Url_tfrnybgkerdrwyzdd2thnekbt1cu5cus\1.0.0.0\user.config line 3)
   bei System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   bei System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
   bei System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
   bei System.Configuration.ClientConfigurationSystem.OnConfigRemoved(Object sender, InternalConfigEventArgs e)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Configuration.ClientConfigurationSystem.OnConfigRemoved(Object sender, InternalConfigEventArgs e)
   bei System.Configuration.Internal.InternalConfigRoot.OnConfigRemoved(InternalConfigEventArgs e)
   bei System.Configuration.Internal.InternalConfigRoot.RemoveConfigImpl(String configPath, BaseConfigurationRecord configRecord)
   bei System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   bei System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   bei System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
   bei System.Data.SqlClient.SqlConnection..cctor()
   --- Ende der internen Ausnahmestapelüberwachung ---Was kann dafür dir Ursache sein?

Grüße-

---

Dietrich

Answer 1

Es deutet darauf hin, dass du die Verbindungseigenschaft zur neuen Datenbank in deiner App.Config falsch konfiguriert hast.

"Failed to read the configuration section for enclave providers."

https://docs.microsoft.com/de-de/sql/relational-databases/security/encryption/always-encrypted-enclaves?view=sql-server-ver15

Answer 2

Wahrscheinlich nicht. SQL-Server 2016.
Wo kann ich die herbekommen?

---

Dietrich

Answer 3

Vielleicht konfigurierst du die Verbindung in einem neuen Projekt erst mal über Visual Studio.
Die Connection aus der App.Config kannst du dann in dein aktives Projekt übernehmen.

Answer 4

Es ist ein älteres Projekt, das auf dem Entwicklungscomputer sauber läuft. Deshalb habe ich es auf den anderen Computer kopiert. Das habe ich auch schon mit anderem Programm und entsprechender Datenbank problemlos gemacht.

Auf dem neuen Computer ist VisualStudio nicht vorhanden, nur SQL-Server und SSMS.

Im Programm mache ich die Verbindung nur einfach via ConnectionString.

Die App.config sieht so aus:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
    </configSections>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2"/>
    </startup>
</configuration>

Grüße-

---

Dietrich

Answer 5

Dann stellt sich die Frage, wie du das im Code zur Laufzeit machst.
Ggf. hast du ein Framework (Entity o.ä.) verwendet, denn die Fehlermeldung deutet darauf hin, dass der Typ der Verbindung mit den übergebenen Config-Daten nicht zurecht kommt, also quasi inkompatibel ist:

"System.TypeInitializationException"

Dies kommt normalerweise bei einer Deserialisierung eines Objects vor.
Poste mal den Code des Verbindungsaufbaues.

Wenn es aber auf dem Entwicklungsrechner läuft und auf dem Zielrechner nicht, gibts u.U. eine falsche/alte Runtimeversion des SQL-Clients.

Answer 6

        connectString = "Data Source=" + serverName _
                + ";Initial Catalog=" + dataBankName _
                + ";Integrated Security=SSPI;TimeOut=300"
        Try
            connection = New SqlConnection(connectString)
            connection.Open()
        Catch ex As Exception
            MessageBox.Show(ex.ToString + vbCrLf + vbCrLf + connectString)
        End Try

Ich habe auch versucht auf dem neuen Rechner NetFramework 4.7.2 zu installieren, ging aber nicht, weil "Es ist ein neueres Framework installiert"...

Wie kann ich feststellen, welches Framework auf dem neuen Rechner verfügbar ist?

---

Dietrich

Answer 7

Ich habe mal nach Server-Konfiguration geschaut. Dabei stieß ich auf das:

Es fällt auf, dass SQL Server Configuration Manager zweimal vorkommt.. !!
Sollte ich vielleicht Server und SSMS deinstallieren und neu installieren?

---

Dietrich

Answer 8

Vielleicht noch ein Hinweis: Auf dem Entwicklungsrechner habe ich SQL2019, auf dem anderen SQL2016 (deshalb habe ich auch die Datenbanken mittels Scripts portiert).

Ein zweites Programm läuft allerdings mit vollkommen gleicher Verbindungs-Programmierung ohne irgendwelche Probleme...

---

Dietrich

Answer 9

Von der Assembly her macht das normalerweise keinen Unterschied, da man im Connectionstring keinen Unterschied in den Versionen hat.
Welche Net-Runtime installiert ist, kannst du mit der Eigenschaft (Details) der Assembly feststellen:
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\System.Core.dll

Nur ein Versuch:

connection = New SqlConnection()
connection.ConnectionString = connectString;

Für die korrekte Bildung eines Connectionstrings empfehle ich dir die Verwendung des ConnectionStringBuilders:
https://docs.microsoft.com/de-de/dotnet/api/system.data.sqlclient.sqlconnectionstringbuilder?view=netframework-4.8

Die Frameworkversion ist da unerheblich.

Bzgl. des Netframeworks 4.8 habe ich schon von verscheidenen Inkompatibilitäten gehört, vor allem auf älteren Windowsversionen. Notfalls kann man versuchen, das Framework mittels Deinstallation der entsprechendne KB zurückzuschrauben.

Vergleiche mal die Version der System.Data.dll zwischen den verschiedenen Systemen.

Answer 10

Danke erst mal für die bisherige Mitarbeit @Suchenden,,,

Seit einigen Jahren bilde ich den ConnectionString wie in einem vorhergehenden Post von mir gezeigt. Und es gab NIE Probleme. Nur eben jetzt wie geschildert.

Das NetframeWork 4.8 habe ich noch nicht sondern 4.7.2.
Zu den Systemen: Alt-PC Windows 10 pro mit SQL-Server 2019, Neu-PC Windows 10 home mit SQL-Server 2016.

Folgendes habe ich noch bemerkt:
Auf dem neuen PC gibt es 5 verschiedene NetFramework-Versionen unter
ProgrammFiles\Referenc Assemblies...., und zwar v3.5, v4.0, v4.5. v4.5.1., v4.5.2
während ich das betreffende Projekt unter v4.7.2 erstellt habe.
Werde es jetzt mal auf v4.5.2 umstellen.

---

Dietrich

PS. Hat auch nichts gebracht... dieselbe Fehlermeldung. Jetzt deinstalliere ich alles.

Answer 11

Die Versionen vor 4.0 befinden sich alle in separaten Verzeichnissen, zu sehen unter %WINDIR%/Microsoft.Net/Framework bzw. .../Framework64.
Seit Version 4.0 befinden wir uns wieder in der alten "DLL-Hölle", da die aktuelle Version immer im Verzeichnis von 4.0 abgelegt ist. Die App.Configs beschreiben nun nur noch die Mindestversion der Installation.
Leider kommt es da nun immer mal wieder zu Inkompatibilitäten, daher DLL-Hälle, wie zu C++-Zeiten und den verschiedenen Runtimeversionen derselben DLL's ber SxS-Installationen.

4.8 habe ich daher vermutet und ich halte das für wahrscheinlich, da deine Installation 4.7.2 wegen höherer Version ja gescheitert ist. Das kannt du eben mit den Eigenschaften der System.core.dll überprüfen.

Der ConnectionstringBuilder ist ja nur eine Empfehlung, da sie das Leben (meist) vereinfacht.

Dein Hauptproblem ist der der Fehler "System.TypeInitializationException", also das Erstellen des Objects SQLConnection. Was dem da fehlt, ist nur schlecht zu verifizieren.

Die Minimumanforderung 4.7.2 erfordert ja das passende Framework. Wenn dies nicht installiert wäre, könnte dein Programm erst gar nicht starten.

By the way:
Die DBProvider möchten die zur Runtime gehörende "machine.config" (im .Net-Verzeichnis) lesen.
Ich hatte da mal einen Kunden, der die Berechtigung zum Lesen für "Jeder" entzogen hatte, so dass tatsächlich keine Datenverbindungen mit .Net mehr möglich waren.
Der Fehler ist ja, dass eine Konfiguration nicht korrekt ist. Vielleicht hat da ja jemand was manipuliert.

Vergleiche also deine machine.config mit der des fehlerhaften PC's, sowohl Inhalt als auch Berechtigung.
Was da allerdings falsch sein könnte, kann ich dir auch nicht sagen.

Answer 12

Hallo,
nun habe ich auf dem "Problem-PC" SQL-Server und SSMS deinsatlliert und wieder neu installiert.
Und: kein Effekt.

Zwischenfrage zum Ordner Windows\WinSxS: Was bedeutet dieser Ornder? In meinem Entw.-PC enthält der mehr als 15.000 Einträge (immerhin ca. 10 GB!!!), beim Problem-PC mehr als 26.000.
Kann man da irgendwas löschen?

Später berichte ich mehr zu machine.config...  (alles unglaublich unübersichtlich)

---

Dietrich

Answer 13

Löschen nicht, nur PC plattmachen und neu aufsetzen.
Das Löschen kann und wird zum Absturz deiner installierten Software führen.
Die 10GB sind durchaus normal.

WinSXS sind sog. SideBySide-Installationen um identisch benannte DLL's, die sonst in System32 installiert wurden, getrennt nach Versionen (Signatur) verwenden zu können.
Programme, die das unterstützen, geben in ihrer jeweiligen App.Config/App.manifest-Datei an, welche Version benötigt wird. Mainifestedateien können in Apps auch als ressource eingebettet sein.

Hintergrund ist die DLL-Hölle, die Microsoft es nicht geschafft hat ihre C++-Runtimes abwärtskompatibel zu halten. Stichworte "vc_redist", Common-Controls.

Vista hat es sogar ganz toll getrieben (daher auch so langsam und kaum eingesetzt) und komplette Programmpakete mit allen ihren DLL's ins SxS installiert.

Was deinen Problem-PC angeht fällt mir auch nicht mehr ein, als ihn komplett neu aufzusetzen.
Ursache kann auch häufig eine bisher funktionierende Migration von Win7/8 sein, da dann zuviel Mist ggf. mitgeschleppt wurde.

Answer 14

Danke vielmals für die Erläuterungen!!!

Allerdings hatte ich den Problem-PC erst im Januar neu aufgesetzt, hatte bloß Probleme beim Installieren von SQL-Server, den ich zweimal wieder deinstalliert habe, bis ich die richtige Version hatte.- Das kam daher, weil der PC noch ein 32Bit-Rechner mit relativ kleiner Platte ist.

OK, bis später!

---

Dietrich

Answer 15

Dann ist 32 Bit dein Problem, da neuere SQL-Server mit 32.Bit nicht mehr funktionieren.
Ggf. betrifft dies ebenso die SQL-Client-Driver.

Answer 16

Das kann wohl nicht sein:

Es ist installiert SQLEXPRADV_x86_DEU.exe (SQL 2014) und andere Programme mit Datenbanken, die via diesem Server vollkommen problemlos laufen. Es geht nur um eines meiner Programme, das den genannten Fehler bei Connection bringt, obwohl die zugehörige Datenbank via SSMS 2016 und Server 2014 ebenfalls problemlos verbunden und im SSMS auch in allen Belangen benutzbar ist.
Es muss am Programm liegen, welches allerdings auf dem 64 Bit-Rechner mit Server 2019 und im Debug-Modus (VS2019) einwandfrei läuft.

Ich tendiere dazu, die Ursache beim Visualstudio zu suchen - aber wo...
Vielleicht eine Diskrepanz bei den Verweisen, denn da gibt es ja auch jede Menge verschiedener Versionen bei den System-Komponenten.

---

Dietrich

Answer 17

Schraube mal die Anforderungen der .Net-Version auf 4.5 oder sogar 4.0 runter, stelle fix "für X86/32-Bit" ein und teste das dann mal auf deinem Entwicklungsrechner.
Vielleicht wirst du dann fündig.

Ich meine gelesen zu haben, dass der 2019er nicht mehr mit 32-Bit funktioniert.
Mir gehen einfach die Ideen aus, da 32-Bit bei mir nicht mehr vorkommt;-).

Answer 18

Hallo,
ich weiß nicht, ob dein Tipp vom obigen Post sinnvoll ist, weil andere Programme auch mit v4.6.2. und AnyCPU funktionieren. Dann müsste auch das betreffende Programm funktionieren.
Aber Folgendes:

Dise Verweise befinden sich in dem Ordner C:\Program Files (x86) des Entwicklungsrechners.
Der Problemrechner zeigt aber diesen Ordner nicht, sondern da gibt es nur den Ordner C:\Programme obwohl er eigentlich ein 32Bit-Rechner ist. Sollte ich diesen Ordner (x86) anlegen und Systembestandteile hinein kopieren?

---

Dietrich

Answer 19

Wenn du Verweise hast, die nicht auf die Net-Runtime verweisen, solltest du beim Verweis "lokale Kopie" wählen.
Dann kannst du deinen Bin-Ordner deployen (also verteilen), da er alles enthält was du zur Laufzeit benötigst außer der .Net-Runtime selber. Es hat weiter den Vorteil, dass du von zufälligen Installationen unterschiedlicher Versionen auf dem Zielsystem unabhängiger bist. Es werden immer die Assemblies deines Bin-/Programmordners gezogen und man kann durch die Wahl verschiedener Ordner auch mehrere Versionen parallel betreiben (z.B. Previews).

Was die Programmordner angeht, so gilt halt die folgende Regel:

Auf 64-Bit-Systemen gibt es "Programme (x86)" für 32-Bit-Umgebungen und "Programme" für 64-Bit.
Zur Laufzeit biegt Windows bestimmte Zugriffe automatisch um:

Bei 64-Bit wird auf den Ordner "Programme" und "%$windir%/System32" direkt zugegriffen.
Bei 32-Bit wird bei diesen Zugriffen auf "Programme (x86)" und "%windir%/syswow64" umgeleitet.

Auf einem 32-Bit-System gibt es ja kein 64-Bit, somit sind die Zugriffe alle auf "Programme" bzw. "%windir%/system32".
Einen Ordner "Programme (x86)" anzulegen bringt da nichts, da er ja nichts enthält, dort nichts installiert wird und in der PATH-Umgebungsvariable nicht enthalten ist.

Fazit:
Wenn dein Programm Verweise auf x86-Assemblies enthält, hast du natürlich auf 32-Bit ein Problem da die Verweise "Absolut" sind.

Answer 20

Hallo,

also es ist ein bisschen unglaublich, wie diese Sache sich aufgelöst hat, obwohl immer noch nicht klar ist, was die wirkliche Ursache ist.

Das betreffende Problemprogramm hatte ich, wie die anderen auch auf Laufwerk D: des Problemcomputers gespeichert. Alle, außer dem P-Programm, liefen ohne Beanstandung (mit der identischen Programmierung bzgl. Connection-Aufbau).
Jetzt habe ich das P-Programm einfach mal auf die Platte C: kopiert und siehe da - Erfolg!!!
Das ist für mich aber doch ein Rätsel, denn die Datenbank liegt nach wie vor auf D:.
OK, nehmen wir es mal so hin und freuen uns auf Ostern!

Allen hier trotz der Umstände schöne Feiertage natürlich bei Gesundheit!

Grüße-

---

Dietrich