Question

We have a Windows app that interrogates two databases then makes some files and puts them on an FTP site. It also recovers files from the FTP site and updates the databases.

This app is all about the data and the files hence my leaning towards the CLR approach (at which I am a beginner)

We are thinking that we could put the business logic into a CLR assembly(s) and execute the logic via SQL Server Agent jobs (execute stored procedure Doit say daily). Essentially automating the processes.

We have complete control over the FTP site and the database server so things like 'UNSAFE' are not a problem.

My question is:

Given the need to access the FTP site and two databases, is this a reasonable use of the technology?

thanks

Was it helpful?

Solution

I don't think so. Typically I use CLR functions/procs in SQL Server when I must perform a certain task in SQL Server that cannot be easily done. One example was performing a regex search on data. This was quite a while ago so I'm not sure if there is a better way to do it now, but at the time a CLR function was a realistic option.

For your situation I would envision a .NET application that uses standard methods to access the databases, FTP stuff, and do whatever else. If you want to run that job daily you could setup a task in windows scheduler to run it.

OTHER TIPS

I have a few apps that do something similar. It's certainly a valid use-case for the CLR technology.

However I'd lean towards using an SSIS package if possible. It's the (much more) usual approach for something like this. In my case I used CLR assemblies because my business logic was very convoluted, and it was easier for me to code that in C# than in SSIS.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top