>>>>>>>@All,
>>>>>>>
>>>>>>>We are investigating whether it would be possible to return a file somewhere that the SQL server service has access to by calling a stored procedure.
>>>>>>>We do not want to store the file itself in the database, but we want to return and store the through simple calls through ODBC.
>>>>>>>
>>>>>>>Is there anything like that possible ? Wihtout using CLR ?
>>>>>>>
>>>>>>>Walter,
>>>>>>
>>>>>>If it is SQL server, then what is wrong with storing the files in the database (while physically they are separately on the disk)? You would then simply read/write them as a regular field. Check FILESTREAM attribute if file sizes are above 1 Mb.
>>>>>
>>>>>It bloats the database.
>>>>
>>>>Not FILESTREAM. Read the doc here for pros and cons : https://msdn.microsoft.com/library/hh461480
>>>
>>>I've been reading that... not sure whether that fits the bill. The datastore of the files need to be stored elsewhere (not on the expensive drives meant for SQL server) on a share. I'm not sure whether that is feasible. Any one knows ?
>>
>>Not my subject but I think the storage must be local. Why are drives on the SQL machine more expensive than other ?
>
>On SQL clusters most often they use enterprise class high performance SSD solutions, while simple drive shares do not demand such storage.
>Our database at university settings is ussually only of of a few dozen on the same SQL server instance.
>
>Walter,

We also have the issue of SSDs and HDDs or the SQL Express database limit.
FILESTREAM are fine.
Handling them with ODBC is like handling a BLOB.
Handling them from W32 is a workmanship.

If the files are approaching 2GB, handling them with VFP starts at become complicated.