3

We had difficulty setting up a FileTable share on a SQL 2014 instance and after giving up on trying to name it after our instance name, we left the name of the share as mssqlserver, but it finally came online, online meaning if you right click in SSMS on the FileTable table you can "Explore FileTable Directory", however it seems to randomly go offline again after some time and you receive the usual canned error message:

So, after magically disabling/enabling FILESTREAM at the server level, database level via t-sql/ssms/configuration manager it some how comes back, but I have to mess with the setting at all of those spots for it to come back! and there seems to be no magical sequence of steps that makes it come back.

Has anyone out there experienced this? Will a restart of the service/server help this? If not, will a repair of sql server help?

Paul White
  • 94,921
  • 30
  • 437
  • 687
Eric Swiggum
  • 694
  • 1
  • 12
  • 31

2 Answers2

2

This could be related to KB4492899 - FIX: FileTable database level directory is inaccessible after database startup in SQL Server 2016 and 2017.

SQL Server 2014 (and possibly earlier additions) also appear to be affected and don't appear to have a fix, although the workaround should still work.

The given workaround requires all existing connections to be closed.

Here are the contents of the KB article, just in case the link is broken in the future:

Symptoms

During Microsoft SQL Server 2016 and 2017 startup, if a user tries to connect to a database before it is started, the user session may cause the database to be auto-started. When this occurs, if the database contains a FileTable and has FILESTREAM non_transacted_access enabled, then the database-level FileTable directory is inaccessible after database startup. If you try to access the folder through File Explorer, it may indicate that the folder is unavailable. When you run a "dir" command from Command prompt, it returns "The system cannot find the file specified."

Additionally, you may see the following errors in the error log that indicate a user session triggered the database to auto-start:

  • DateTime Logon Error: 18456, Severity: 14, State: 38.
  • DateTime Logon Login failed for user 'UserName'. Reason: Failed to open the explicitly specified database 'DatabaseName'. [CLIENT: IPNumber]

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

Resolution

This issue is fixed in the following cumulative updates for SQL Server:

Cumulative Update 15 for SQL Server 2017

Cumulative Update 6 for SQL Server 2016 SP2

About cumulative updates for SQL Server:

Each new cumulative update for SQL Server contains all the hotfixes and all the security fixes that were included with the previous cumulative update. Check out the latest cumulative updates for SQL Server:

Latest cumulative update for SQL Server 2017

Latest cumulative update for SQL Server 2016

Workaround

The workaround for this issue is to disable and re-enable the FILESTREAM non_transacted_access of the database.

ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

ALTER DATABASE [DatabaseName] SET FILESTREAM ( NON_TRANSACTED_ACCESS = OFF )


ALTER DATABASE [DatabaseName] SET FILESTREAM ( NON_TRANSACTED_ACCESS = FULL )


ALTER DATABASE [DatabaseName] SET MULTI_USER WITH ROLLBACK IMMEDIATE
timb
  • 136
  • 2
1

It appears that after setting it via configuration manager the issue went away.

Eric Swiggum
  • 694
  • 1
  • 12
  • 31