From: jh on 11 Nov 2009 09:36 Uzytkownik "Erland Sommarskog" <esquel(a)sommarskog.se> napisal w wiadomosci news:Xns9CC0920FB7B8DYazorman(a)127.0.0.1... >> That's what you can find in my code: > Good! But did you ever tell us what the message box said? :-) Yes, I did in my first post: "LastError (6) means INVALID FILE HANDLE" > It doesn't whether the filename is Unicode in the table. But value you > pass to OpenSqlFilestream must be a pointer to a Unicode string. I'll try this, thank you. > Eh, wait a minute. I looked your code last night about the last thing I > did. I might have been a little tired... I can't see that you set > FSQLFilePath anywhere. You should get the value with the PathName function > from SQL. That part seems to be missing. (Disclaimer: I'm at work now, and > I don't have the time look in the SQL 2008 docs, so I talk from memory.( In my last post I wrote about the trigger: SET [BLOBPath] = CONVERT(varchar(max), i.[BLOBData].PathName()) so the proper path is filled everytime I store BLOB in a table and it uses PathName() method of FILESTREAM column. Regards, Jacek
From: Bob Beauchemin on 11 Nov 2009 09:57 Are you trying to use the handle off-host (e.g. from a machine other than the one where SQL Server is running?). If so, don't forget to open the port for SMB on the SQL Server box. You would think that not having the port open would produce a different error message though. Cheers, Bob Beauchemin SQLskills "jh" <NIE_SPAMUJ_jh(a)radio.kielce.pl> wrote in message news:hdei5s$ar4$1(a)inews.gazeta.pl... > Uzytkownik "Erland Sommarskog" <esquel(a)sommarskog.se> napisal w wiadomosci > news:Xns9CC0920FB7B8DYazorman(a)127.0.0.1... >>> That's what you can find in my code: > >> Good! But did you ever tell us what the message box said? :-) > > Yes, I did in my first post: "LastError (6) means INVALID FILE HANDLE" > > >> It doesn't whether the filename is Unicode in the table. But value you >> pass to OpenSqlFilestream must be a pointer to a Unicode string. > > I'll try this, thank you. > > >> Eh, wait a minute. I looked your code last night about the last thing I >> did. I might have been a little tired... I can't see that you set >> FSQLFilePath anywhere. You should get the value with the PathName >> function from SQL. That part seems to be missing. (Disclaimer: I'm at >> work now, and I don't have the time look in the SQL 2008 docs, so I talk >> from memory.( > > In my last post I wrote about the trigger: SET [BLOBPath] = > CONVERT(varchar(max), i.[BLOBData].PathName()) so the proper path is > filled everytime I store BLOB in a table and it uses PathName() method of > FILESTREAM column. > > Regards, > Jacek
From: jh on 11 Nov 2009 10:23 Uzytkownik "Bob Beauchemin" <no_bobb_spam(a)sqlskills.com> napisal w wiadomosci news:uWLxU9tYKHA.3712(a)TK2MSFTNGP06.phx.gbl... > Are you trying to use the handle off-host (e.g. from a machine other than > the one where SQL Server is running?). I tried running the program from the remote machine and from the server itself. Sharing files and printers was enabled, also tried with firewall turned off. Regars, Jacek
From: Erland Sommarskog on 11 Nov 2009 17:33 jh (NIE_SPAMUJ_jh(a)radio.kielce.pl) writes: > In my last post I wrote about the trigger: SET [BLOBPath] = > CONVERT(varchar(max), i.[BLOBData].PathName()) so the proper path is > filled everytime I store BLOB in a table and it uses PathName() method > of FILESTREAM column. I'm not sure that I see the point with this. Or even if it is a good idea. What if SQL Server decides to reorganize the data and make the path invalid? I would suggest that you try to retrieve the path at run-time. -- Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se Links for SQL Server Books Online: SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
From: jh on 11 Nov 2009 19:01 Uzytkownik "Erland Sommarskog" <esquel(a)sommarskog.se> napisal w wiadomosci news:Xns9CC0EFA296CCFYazorman(a)127.0.0.1... > I'm not sure that I see the point with this. Or even if it is a good idea. > What if SQL Server decides to reorganize the data and make the path > invalid? Well, the path is build on FILESTREAM file group allocation and the server cannot change it like in any other database files. Server share path cannot be change - you can change it in server service settings. File name cannot be change because it's based on GUID stored in the table... So I can't see no reason for changing the path by the server itself. What's more, it's only for testing purpose and finally I plan to access the data via view, when I can call for FilePath() method instead of an additinal column in a table. Regards, Jacek
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Script to check the Syntax on all stored procedures in a database Next: Sql Server on VMWare |