SQL Server 2008 Filestream Win32 error without network cable!

Question

I have a SQL Server 2008 database using Filestreaming, and everything works fine and dandy apart from one very strange circumstance. If I have my database, say, a laptop, on a locally installed version of SQL Server 2008, and I'm connected to the network, everything works fine. If I disconnect the network cable, after a while the SqlFileStream class will not be initialized with a Win32 exception (everything else about connecting to the database works fine). If I start a new one without a network cable, it will not work with the same error. If I plug in a network cable even without a network connection, it works ... take it out, nothing.

I connect to a file stream in a regular documented method

SqlFileStream fileStream = new SqlFileStream(path, context, FileAccess.ReadWrite, FileOptions.SequentialScan, 0); 

getting the path and context from a stored procedure that generates them in the following

 SELECT Data.PathName(), GET_FILESTREAM_TRANSACTION_CONTEXT() FROM dbo.DocumentFiles WHERE [File_ID] = @FileId 

I get the following error when creating an SqlFileStream instance

A Win32Exception has occurred. Network location could not be reached. For more information on network troubleshooting, see Windows Help.

There is no internal exception.

I tried so many things to solve the problem without any luck. nobody in google-land seems to have the same problem, so obviously something stupid is what I'm doing. If anyone can shed light on this, I would be very grateful.

James

Answer 1

Hm. It looks like your network interface is disconnecting when you disconnect the cable. When this happens, the TCP / IP stack also drops, as there are no more interfaces available. I suggest you install the Loopback MS adapter, this article explains how to do this in Windows XP; how to do this on other operating systems is easy. Remember to assign it a static IP address after installation, a private address such as 192.168.1.x is enough. Since the loopback adapter is virtual, it is always in the “Up” state, even when you disconnect the cable, and this prevents the Windows TCP stack from closing.