LocalDB v14 erstellt einen falschen Pfad für MDF-Dateien

Kürzlich habe ich LocalDB mit dem SQL Server Express-Installationsprogramm und dieser Anleitung von Version 13 auf Version 14 aktualisiert . Nach der Installation habe ich die vorhandene Standardinstanz (MSSQLLOCALDB) von Version 13 gestoppt und eine neue erstellt, die automatisch die Server-Engine der Version 14.0.1000 verwendet.

Ich verwende LocalDB häufig für Datenbankintegrationstests, dh ich erstelle in meinen xunit-Tests eine (temporäre) Datenbank, die nach Abschluss des Tests gelöscht wird. Seit der neuen Version schlagen leider alle meine Tests wegen folgender Fehlermeldung fehl:

Beim Versuch, die physische Datei "C: \ Users \ kepflDBd0811493e18b46febf980ffb8029482a.mdf" zu öffnen oder zu erstellen, ist beim Erstellen einer Datei der Betriebssystemfehler 5 aufgetreten (Zugriff verweigert.)

Das Seltsame ist, dass der Zielpfad für die MDF-Datei falsch ist und ein Backslash zwischen C: \ Users \ kepfl und DBd0811493e18b46febf980ffb8029482a.mdf fehlt (das ist der zufällige Datenbankname für einen einzelnen Test). Die Datenbanken werden über den einfachen Befehl erstellt CREATE DATABASE [databaseName]- hier nichts Besonderes.

In SSMS werden die folgenden Zielspeicherorte für Daten, Protokoll und Sicherung angezeigt:

Wenn ich jedoch versuche, den Speicherort zu aktualisieren, wird eine andere Fehlermeldung angezeigt:

Wie kann ich die Standardspeicherorte aktualisieren, damit LocalDB erneut Datenbanken erstellen kann? Es ist offensichtlich, dass LocalDB das Standardverzeichnis und den Namen der Datenbankdatei nicht korrekt kombiniert. Gibt es einen Registrierungseintrag, den ich bearbeiten kann? Oder sonst noch etwas?

Update nach Dougs Antwort und Sepupics Kommentar

Gemäß dieser Stackoverflow-Frage sollten die Standardspeicherorte auch über die Registrierung änderbar sein. Wenn ich jedoch versuche, die entsprechenden Schlüssel "DefaultData", "DefaultLog" und "BackupDirectory" zu finden, kann ich sie nicht in meiner Registrierung finden. Hat SQL Server v14 diese Registrierungsschlüssel umbenannt oder diese Informationen aus der Registrierung entfernt?

AKTUALISIEREN

Ab CU 6 für SQL Server 2017 wurde dieser Fehler behoben. Es ist nun möglich, Folgendes erfolgreich auszuführen:

CREATE DATABASE [CreateDatabaseTest];
DROP DATABASE [CreateDatabaseTest];

Das Problem und die Tatsache, dass es in CU6 behoben wurde, sind im folgenden KB-Artikel dokumentiert:
UPDATE: Fehler "Zugriff verweigert" beim Versuch, eine Datenbank in SQL Server 2017 Express LocalDB zu erstellen

Um das kumulative Update zu erhalten, rufen Sie die folgende Seite auf und greifen Sie auf den neuesten Build zu, der möglicherweise neuer als CU6 ist. Dies hängt davon ab, wann Sie dies sehen:

SQL Server 2017-Buildversionen

UNTEN INFO OBSOLETE AB SQL SERVER 2017 CU6 (Veröffentlicht am 17.04.2018)

Das Fehlen eines Backslashs im kombinierten Pfad + Dateinamen scheint ein Fehler in SQL Server 2017 zu sein. Ich bin selbst darauf gestoßen. Ich habe sogar versucht, die Registrierung so zu bearbeiten, dass ein DefaultDataZeichenfolgenwert für C: \ Users \ MyAccountName \ in beiden folgenden Schlüsseln hinzugefügt wird (die drei Standardpfade befinden sich in keinem der von mir durchsuchten LocalDB-Registrierungsschlüssel):

• Computer \ HKEY_CURRENT_USER \ Software \ Microsoft \ Microsoft SQL Server \ UserInstances \ {irgendein-GUID-Wert}
• Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL14E.LOCALDB \ MSSQLServer

Und ja, ich habe die LocalDB-Instanz in beiden Versuchen heruntergefahren und neu gestartet.

Ich bin jedoch nicht davon überzeugt, dass es ein Fehler ist, die Standardpfade nicht ändern zu können, da dies möglicherweise nur zu einer schlechten Dokumentation und einer schlechten Fehlerbehandlung führt. Ich sage das, weil ich gerade versucht habe, die Standardspeicherorte für die SQL Server LocalDB-Versionen 2014, 2016 und 2017 zu bearbeiten, und alle genau den gleichen Fehler ergeben haben, der an sich seltsam ist, weil er von stammt RegCreateKeyEx(), der sich mit der Registrierung und befassen sollte nicht das Dateisystem.

Es ist bedauerlich, den Pfad nicht ändern zu können, da beim Erstellen einer neuen Datenbank kein Backslash auftritt, ohne die zu verwendenden Dateien anzugeben. Ich konnte jedoch eine neue Datenbank mit der folgenden vollständigen CREATE DATABASESyntax erstellen :

CREATE DATABASE [XXXXX]
 CONTAINMENT = NONE
 ON PRIMARY 
( NAME = N'XXXXX_sys', FILENAME = N'C:\Users\MyAccountName\XXXXX_sys.mdf',
  SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 65536KB ), 
 FILEGROUP [Tables] DEFAULT
( NAME = N'XXXXX_data', FILENAME = N'C:\Users\MyAccountName\XXXXX_data.ndf',
  SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 65536KB )
 LOG ON 
( NAME = N'XXXXX_log', FILENAME = N'C:\Users\MyAccountName\XXXXX_log.ldf',
  SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 65536KB )
 COLLATE Latin1_General_100_CS_AS_KS_WS_SC;
GO

Ich bin auf dasselbe Problem gestoßen und habe eine Problemumgehung gefunden, die keine eindeutigen Nachteile haben sollte (wenn ich etwas vergesse, korrigieren Sie mich bitte) . Es basiert auf der Antwort von Solomons, ohne dass der absolute Pfad zu den Datenbankdateien direkt angegeben werden muss.

DECLARE @databaseName NVARCHAR(MAX) = 'MyDatabase'

DECLARE @dataFilePath NVARCHAR(MAX) = CAST(SERVERPROPERTY('InstanceDefaultDataPath') AS NVARCHAR) 
    + FORMATMESSAGE('\%s.mdf', @databaseName)

DECLARE @sql NVARCHAR(MAX) = FORMATMESSAGE(
    'CREATE DATABASE %s ON PRIMARY ( NAME = %s, FILENAME = ''%s'' )', 
    quotename(@databaseName), quotename(@databaseName), @dataFilePath
)

EXEC (@sql)

Es verwendet dynamisches SQL und ist nicht gerade hübsch, aber es erledigt den Job, bis es eine offizielle Lösung für das Problem gibt.

Ich stehe auch diesem Problem gegenüber. Die einzige Problemumgehung, die ich gefunden habe, wäre c:\Users\, jedem (oder so ähnlichem) Schreibzugriff zu gewähren und die MDF-Dateien erstellen zu lassen, wo immer sie möchten.

Vielen Dank für Ihre kurze Erklärung dieses Problems. Ich bin gestern auf dasselbe Problem gestoßen. Ich habe noch keine dauerhafte Lösung gefunden, aber hier ist meine aktuelle Problemumgehung.

Ich benutze die Database.EnsureCreated () - Funktion, um die Datenbank zu erstellen.

Stellen Sie die Verbindungszeichenfolge so ein, dass sie die Einstellung ' AttachDBFilename = ' enthält.

Server=(LocalDB)\\MSSQLLocalDB;Database=ExploreCalifornia;AttachDbFilename=.\\ExploreCalifornia.mdf;Trusted_Connection=True;MultipleActiveResultSets=true

Führen Sie die Anwendung aus. Es wird ein Fehler generiert:

Die Datei '. \ ExploreCalifornia.mdf' kann nicht als Datenbank 'ExploreCalifornia' angehängt werden.

aber es wird die Datenbank erstellen.

Ändern Sie danach die Verbindungszeichenfolge und entfernen Sie ' AttachDBFilename = '.

 Server=(localdb)\\MSSQLLocalDB;Database=ExploreCalifornia;Trusted_Connection=True;MultipleActiveResultSets=true

Ich habe die Anwendung erneut ohne Fehler ausgeführt und Tabellen wurden erstellt.