views:

52

answers:

1

I have many (>600) EPS files(300 KB - 1 MB) in database. In my ASP.NET application (using ASP.NET 4.0) I need to retrieve them one by one and call a web service which would convert the content to the JPEG file and update the database (JPEGContent column with the JPEG content). However, retrieving the content for 600 of them itself takes too long from the SQL management studio itself (takes 5 minutes for 10 EPS contents).

So I have two issues:-

1) How to get the EPS content ( unfortunately, selecting certain number of content is not an option :-( ):-

Approach 1:-

foreach(var DataRow in DataTable.Rows)
{
// get the Id and byte[] of EPS
// Call the web method to convert EPS content to JPEG 
}

or

foreach(var DataRow in DataTable.Rows)
{
// get only the Id of EPS
// Hit database to get the content of EPS
// Call the web method to convert EPS content to JPEG
}

or

Any other approach?

2) Converting EPS to JPEG using a web method for >600 contents. Ofcourse, each call would be a long running operation. Would task parellel library (TPL) be a better way to achieve this?

Also, is doing the entire thing in a SQL CLR function a good idea?

EDIT :- Unfortunately, I have to do this in the ASP.NET application itself and doing that in a separate process like Windows service is not an option.

+1  A: 

This approach seems fundamentally wrong to me. If, as you suggest in approach 1, your service is capable of hitting the database itself (to update it), then why isn't your service doing the work of pulling the content out?

I'd be tempted to do something like...

1) (possibly) add a column to your table to flag whether the EPS has been translated, potentially store the result of the translation as well.
2) If you absolutely have to kick the process off from ASP.NET, either
a) call the database from your front-end and get the ids that have not yet been translated and pass them to the service for translation, or
b) just issue a call to the service saying "convert all unconverted eps files now"
3) A better alternative would be to have a scheduled job running somewhere that will do the conversion. This means your ASP.NET processes aren't sitting around waiting for the conversion to run.

Passing the data around over the wire seems unnecessary to me, but I realise I don't know how the servers are physically located or the capabilities of your network.

ZombieSheep
" then why isn't your service doing the work of pulling the content out?" -- because, that service is generic and could be shared across many other applications and can not have application specific code to pull data. It just takes a byte[] of EPS and returns byte[] of JPG.
ydobonmai
OK. It still "smells" wrong to me, but if that's they way it is then so be it.
ZombieSheep
Dont think there is anything wrong with this. A simple reusable service for a simple job without any dependency.
ydobonmai
Fair enough - I'm not trying to say you're wrong, just that there seems to be a requirement for sending lots of data over the wire that potentially doesn't need to. You mentioned that your service could update the database directly, so I would have thought that would be a good place to get the data from. :)
ZombieSheep
ok, my bad. I was just told that the service is not going to update the database. Sorry for the confusion.
ydobonmai