LocalDB v14はmdfファイルの間違ったパスを作成します

最近、SQL Server Expressインストーラーとこの手順を使用して、LocalDBをバージョン13から14にアップグレードしました。インストール後、バージョン13の既存のデフォルトインスタンス（MSSQLLOCALDB）を停止し、v14.0.1000サーバーエンジンを自動的に使用する新しいインスタンスを作成しました。

データベース統合テストによくLocalDBを使用します。つまり、xunitテストでは、テストが終了すると削除される（一時的な）データベースを作成します。新しいバージョン以降、残念ながら次のエラーメッセージが原因ですべてのテストが失敗します。

物理ファイル 'C：\ Users \ kepflDBd0811493e18b46febf980ffb8029482a.mdf'を開くまたは作成しようとしたときに、CREATE FILEでオペレーティングシステムエラー5（アクセスが拒否されました）が発生しました。

奇妙なことは、mdfファイルのターゲットパスが正しくないことです。C：\ Users \ kepflとDBd0811493e18b46febf980ffb8029482a.mdf（単一のテストのランダムなデータベース名）の間にバックスラッシュがありません。データベースは単純なコマンドで作成されますCREATE DATABASE [databaseName]-ここでは特別なことは何もありません。

SSMSでは、データ、ログ、およびバックアップのターゲットの場所は次のとおりです。

ただし、場所を更新しようとすると、別のエラーメッセージが表示されます。

LocalDBがデータベースを再度作成できるように、デフォルトの場所を更新するにはどうすればよいですか？LocalDBがデフォルトのロケーションディレクトリとデータベースファイル名を正しく結合していないことは明らかです。編集できるレジストリエントリはありますか？または他に何か？

Dougの回答とsepupicのコメントの後の更新

このStackoverflowの質問によると、デフォルトの場所もレジストリ経由で変更可能である必要があります。ただし、対応するキー「DefaultData」、「DefaultLog」、および「BackupDirectory」を見つけようとすると、レジストリでそれらを見つけることができません。SQL Server v14はこれらのレジストリキーの名前を変更しましたか、またはこれらの情報をレジストリから移動しましたか？

更新

SQL Server 2017のCU 6の時点で、このバグは修正されました。以下を正常に実行できるようになりました。

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

この問題、およびCU6で修正されているという事実は、次のKB記事に記載されています。FIX
：SQL Server 2017 Express LocalDBでデータベースを作成しようとすると、「アクセスが拒否されました」エラー

累積更新プログラムを入手するには、次のページに移動して、トップ（つまり、最新の）ビルドを取得してください。

SQL Server 2017ビルドバージョン

SQL Server 2017 CU6の時点で廃止された情報（2018年4月17日リリース）

結合されたパスとファイル名にバックスラッシュがないことは、SQL Server 2017のバグのようです。レジストリを編集して、次のキーの両方にC：\ Users \ MyAccountName \のDefaultData文字列値を追加することも試みました（3つのデフォルトパスは、調べたLocalDBレジストリキーのいずれにもありません）。

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

はい、両方の試行でLocalDBインスタンスをシャットダウンして再起動しました。

ただし、デフォルトのパスを変更できないことはバグであり、ドキュメントとエラー処理の組み合わせが不十分であるだけだとは思いません。これは、SQL Server LocalDBバージョン2014、2016、および2017のデフォルトの場所を編集しようとしたところ、まったく同じエラーが発生したためですRegCreateKeyEx()。これは、レジストリを処理する必要があるため、ファイルシステムではありません。

使用するファイルを指定せずに新しいデータベースを作成する場合、バックスラッシュがないため、パスを変更できないのは残念です。ただし、CREATE DATABASE次のように完全な構文を使用して新しいデータベースを作成できました。

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

私は同じ問題にぶつかり、明らかな欠点がないはずの回避策を見つけました（何かを忘れている場合は、修正してください）。Solomonsの回答に基づいていますが、データベースファイルへの絶対パスを直接指定する必要はありません。

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)

動的SQLを使用しており、正確ではありませんが、問題に対する公式の修正が行われるまで仕事は完了します。

私もこの問題に直面しています。私が見つけた唯一の回避策はc:\Users\、Everyone（またはそのようなもの）への書き込みアクセスを許可し、必要な場所にmdfファイルを作成できるようにすることです。

この問題について簡潔に説明していただきありがとうございます。昨日、この同じ問題に遭遇しました。私はまだ永続的な解決策を見つけていませんが、ここに私の現在の回避策があります。

Database.EnsureCreated（）関数を使用してデータベースを作成しています。

接続文字列を設定して、「AttachDBFilename =」設定を含めます。

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

アプリケーションを実行します。エラーが生成されます：

ファイル「。\ ExploreCalifornia.mdf」をデータベース「ExploreCalifornia」として添付できません。

しかし、データベースを作成します。

その後、接続文字列を変更し、「AttachDBFilename =」を削除します。

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

エラーなしでアプリケーションを再度実行し、テーブルが作成されました。