Hi

I need to run backend jobs that run daily/monthly and
perform tasks ranging from setting the status on an
expired policy to more complex period end preium earnings
computations. Is it best to do these using SQL/DTS or use
middle tier .Net objects ? What are some design
consideration in choosing one over the other ?

Thanks,

Venkatesh

well it is more Number/data crunching? or do you need to use other
resources such as the files system for moving data files around?

if pure numer data then use SQL.

if data importing then use DTS

if business processing then use .NET

just some simple points... although this will really depend on your task

"Venkatesh" <(E-Mail Removed)> wrote in message
news:10ad701c3f4d5$e8540e20$(E-Mail Removed)...
> Hi
>
> I need to run backend jobs that run daily/monthly and
> perform tasks ranging from setting the status on an
> expired policy to more complex period end preium earnings
> computations. Is it best to do these using SQL/DTS or use
> middle tier .Net objects ? What are some design
> consideration in choosing one over the other ?
>
> Thanks,
>
> Venkatesh
>
>

If you need to do complex processing, then you should use .NET instead of SQL/DTS. I think it's more flexible using .NET especially when you have all of your business logic done in .NET already

Tu-Thac

----- Venkatesh wrote: ----

H

I need to run backend jobs that run daily/monthly and
perform tasks ranging from setting the status on an
expired policy to more complex period end preium earnings
computations. Is it best to do these using SQL/DTS or use
middle tier .Net objects ? What are some design
consideration in choosing one over the other

Thanks

Venkates

I would suggest doing as much as possible in SQL server, but I guess it's kind of a personal preference

By using SQL, you can schedule the jobs to run in off-hours and not have to rely on a PC to kick off the job (assuming your SQL server is always running/has better uptime than your PCs)

Also, I try to go by the rule that (generally) the fewer layers in an application, the better. Running the majority of your code on SQL means you have less network traffic, especially if some of your more in-depth functions need a lot of data to be calculated

If you need a more visualally appealing solution, you could try running most of the calculations in SQL, then writing the products to temporary tables, then have your Win/Web app pull only the final results from the temporary tables for formatting purposes.