<p>I've got a UI front end which talks to and manipulates a SQL Server database, and one of the things it can do is run reports on the data in the database. </p>

<p>This UI can be installed on multiple computers, and so far I've just been keeping the reports in a folder with the install, but this means that any time a new report is added is has to manually be copied to every single UI install out there.</p>

<p>I was thinking of storing the .rpt files in the database itself (As Blobs) and having some mechanism for the UI to fetch them when needed as a way to centralize the reports and eliminate this issue.</p>

<p>Has anybody tried this, and did it work well? Or if you haven't, can you think of anything I should take into account before moving forward with this? Are the any tips, tricks, or caveats you can think of that might be helpful to me?</p>

Here's great podcast with Paul Randal (he wrote parts of DBCC!) where they talk about the new filestream feature in sql server 2008  for handling blobs, but they also go into the sizes of files that do and don't work well
as blobs as part of the talk. I think it would help you.
http://www.runasradio.com/default.aspx?showNum=74
I just found out that the 25-page FILESTREAM whitepaper Paul wrote has has been published on MSDN.
http://msdn.microsoft.com/en-us/library/cc949109.aspx
.
Based on the research cited later in this white paper, BLOBs smaller than 256 kilobytes (KB) (such as widget icons) are better stored inside a database, and BLOBs larger than 1 megabyte (MB) are best stored outside the database. For those sized between 256 KB and 1 MB, the more efficient storage solution depends on the read vs. write ratio of the data, and the rate of “overwrite”. Storing BLOB data solely within the database (e.g., using the varbinary(max) data type) is limited to 2 gigabytes (GB) per BLOB.