views:

143

answers:

1

I have a SQL Server 2008 database utilizing Filestreaming and all works fine and dandy apart from under one very strange circumstance. If i have my database on, say a laptop, on a locally installed version of SQL Server 2008 and am connected to the network all works fine. If i unplug the network cable, after a while the SqlFileStream class fails to initialize with a Win32 exception (everything else about connecting to the database works fine). If i start fresh without a network cable it will not work with the same error. If i plug a network cable in even with no network connectivity it works... take it out, nothing.

I'm connecting to the filestream in the usual documented method

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

geting the path and context from a stored procedure which generates them in the following

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

I'm getting the following error when creating the SqlFileStream instance

Win32Exception occurred The network location cannot be reached. For more information about network troubleshooting, see Windows help.

No inner exception.

I have tried so many things to resolve the issue with no luck. no one in google-land seems to have the same issue so obviously something silly I'm doing. If anyone can shed any light on this i would be most grateful.

James

A: 

Hmm. It looks like your network interface goes down when you unplug your cable. When it happens TCP/IP stack goes down as well since there's no more available interfaces left. I suggest you to to install the MS Loopback adapter, this article explains how to do it in Windows XP; it is easy to google about how to do it in other OSes. Do not forget to assign a static IP to it after installation, private address like 192.168.1.x would be sufficient. Since loopback adapter is a virtual one, it is in "Up" state all the time, even when you unplug your cable and it prevents Windows from shutting TCP stack down.

Igor Korkhov
Would this still be the case if i'm using named pipes as the network library?
James
I followed the instructions (i was returning the loop back address when i was pinging myself) and now all is working. Thank you very much for offering this suggestion. This was really bugging me! This does seem to be a bit of a short coming in the filestream method in 2008 though?
James
No, I don't think that this is a shortcoming in the FileStream method,it looks like you're using TCP/IP to connect to SQL server, and when TCP/IP goes down the connection stops working too. No wonder that SqlFileStream can't retrieve any data, hence the exception. I believe if you start using shared memory or named pipes as a transport, you will no longer need MS loopback adapter, but of course, you will be able to connect to a local instance of SQL server then.
Igor Korkhov
This is very strange as i am using named pipes. This is one of things i tried changing between tcp/ip, named pipes, shared memory and this made no difference. Many thanks again
James
You're welcome, James. I am glad that my solution helped you, but it left me wonder how TCP/IP affected shared memory :)
Igor Korkhov
I suppose it may have something to do with SqlFileStream not actually using the database connection but using a share name set up to access to the filestream location. the Data.PathName() returns a logical path and is set up on the machines shares. I assume when the tcp/ip goes down the shares stop working as well. this is regardless of the sql server connection, which is using shared memory in my case!Might this explain it? or am i still missing something?
James
@James: "I assume when the tcp/ip goes down the shares stop working as well" -- I think that explains everything! SQL server obviously needs a way to retrieve the requested data, which is impossible when tcp/ip is down. Sharing is based on SMB (Server Message Block) protocol, which in turn is based on tcp/ip. No TCP-->No Shared folder access-->No data-->Exception. Thank you for the interesting question, James!
Igor Korkhov