October 25, 2001 at 4:36 pm
We have an external web server that attaches to an internal SQL server via a specific port. When the user submits info from their browser, we want to send it to SQL server, run a program that massages the input into a pdf file, and finally send the pdf file back to the user (via our web server).
Is this type of feat possible using SQL Server?
TIA,
Bill
October 25, 2001 at 8:06 pm
Sure. Leon is actually working on something very similar right now. What we ended up with is a "queue" table on the SQL box. Web server inserts records to process, a job runs the app (a compiled dll in this case) that generates some files, then marks the queue record as done. Depending on how process was initiated, web page polls to find out when complete or user gets email advising them.
We wanted to minimize load for our scenario, so this way we have a max of one instance of the app running. If you tried for more immediate results, you could end up with a LOT of concurrent executions of your app - have to look at performance implications.
Andy
October 25, 2001 at 9:43 pm
Andy,
You mention that "a job runs the app (a compiled dll in this case) that generates some files". How does the job know to start running? Is it setup with the SQL scheduler or does the table have trigger that starts the job.
TIA,
Bill
October 25, 2001 at 10:22 pm
Wouldn't the web server process the request and generate the pdf? We used a product called Active Reports that does this. The web page instantiates the object, calls SQL to get data and generates a pdf which is displayed for the user.
I'd avoid running any process on the SQL Server that generates reports.
Steve Jones
October 26, 2001 at 5:18 am
Bill, we use a scheduled job. You could use a trigger if it was low volume. Steve is right in saying that usually best not to run things on the SQL box, but I'd guess it would depend on how heavily each is loaded. Of course, just because the queue exists in SQL doesn't mean it has to run on the same box. You could easily just write an app that polls for items in the queue and does the work - that could be on any machine.
Andy
October 26, 2001 at 10:30 am
Also, Queue can be either MSMQ or just a table in SQL Server that holds the status about what you are trying to process.
Steve Jones
October 26, 2001 at 10:41 am
MSMQ is pretty neat, but I find that most of the time a table is good enough and one less thing to troubleshoot. I'm open to ideas about why I should change though!
Andy
October 26, 2001 at 1:56 pm
MSMQ is nice if you are concerned about load and want to separate your stuff from the SQL Server. Also, it reduces dependencies and integrates better with some systems (Tuxedo, some mainframe technologies, etc).
Personally, I agree with Andy that a table provides all the benefits, is less technology to worry about and simpler. KISS
Steve Jones
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply