>>>>I'd argue that it certainly *does* belong there - just that the option isn't well supported :-}
>>>>
>>>>Well, I've seen several companies that have stated specific reasons why they wanted to keep them external (reasons ranging from flexibility to system issues I described earlier) - I have yet to see or hear any stated requirement/reason to keep them in the database.
>>>
>>>Unless you've got tight control over the external storage than I would think security/integrity would be a big issue.
>>>No guarantees that the file you are expecting actually exists and, if it does, whether it has been swapped inadvertently or deliberately.
>>>No guarantee that someone hasn't changed the neccessary permissions when you need to add/change/delete a file.
>>>No guarantee that the d***d folder even exists without checking every time......
>>>
>>>You mentioned that there may be backup issues with filestream - but I would think they pale in comparison to any robust strategy for synchronously backing up external files. And varbinary presents no problem there anyway.
>>>
>>>Unless I see a noticeable performance hit from varbinary (which in this instance I don't) I think I'll stick with it. But when I get time I'll try testing a FILESTREAM option.
>>>
>>>Best,
>>>Viv
>>
>>I agree.
>>
>>FILESTREAM is necessary with data > 2GB
>
>Hi,
>Do you mean 2Gb per 'blob' ?
>As mentioned earlier my varbinary rarely has to store more the 1Mb. Somehow I had a gut feeling that FILESTREAM might become a better option at around the 3-5Mb mark (but my gut had no basis for feeling that way). I've never tried putting even something approaching 1GB in a varbinary - are you suggesting that's a viable option ?
>Regards,
>Viv

Sure.
Obviously, blobs data entered must belong to the application environment.
The problem is not on the server side, but the client side,
where you must create a file to use an application that manages the particular blob.