From: jh on
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
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
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
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
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