Embedded Stored Procedure within App

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,

We have an application with is store procedure dependent. I'm looking for a
way to simplify our deployment by embedding Stored Procedures within our
application so that we do not have to "keep track" of which SPs to promote.
Basically if we can just "build and release" that will be idea.

So how do you guys manage your stored procedures? I'm thinking of two
possiblities:

1. Store the SPs in a the resouce file

2. Store the SQL scripts in a folder, then dynamically load the SPs when
they're needed.

I like Option #1 because all required SPs are deployed with the binary...
but editing a resource file is pain with the default VS.NET editor.

Option #2 provides a lot of flexiblity - we can modify SPs to suit certain
customer requirements... but synchronizing releases will be difficult.

Any other ideas?

Thanks!
 
Spam said:
Hi all,

We have an application with is store procedure dependent. I'm looking for a
way to simplify our deployment by embedding Stored Procedures within our
application so that we do not have to "keep track" of which SPs to promote.
Basically if we can just "build and release" that will be idea.

So how do you guys manage your stored procedures? I'm thinking of two
possiblities:

1. Store the SPs in a the resouce file

2. Store the SQL scripts in a folder, then dynamically load the SPs when
they're needed.

I like Option #1 because all required SPs are deployed with the binary...
but editing a resource file is pain with the default VS.NET editor.

Option #2 provides a lot of flexiblity - we can modify SPs to suit certain
customer requirements... but synchronizing releases will be difficult.

Any other ideas?

Thanks!
Click to expand...

I go with option 3:
Build a seperate Update utility that has ALL the stored procedures
(internally, as resources). then it can check the database to see which
updates have already been applied, then it applies the ones it needs.
 
(e-mail address removed) wrote in
I go with option 3:
Build a seperate Update utility that has ALL the stored procedures
(internally, as resources). then it can check the database to see
which updates have already been applied, then it applies the ones it
needs.
Click to expand...

But how do you track the version of a SP?

What if the SP was purposefuly customized for a customer?

Are there custom properties that can be used to flag these sort of details?
 
Spam said:
(e-mail address removed) wrote in


But how do you track the version of a SP?

What if the SP was purposefuly customized for a customer?

Are there custom properties that can be used to flag these sort of details?
Click to expand...

Ahh! all good questions! These issues have not actually been resolved
(this tool was just started last Friday! ;)).
But yes, I will have to deal with these some time soon. I'm not too
worried about SP versioning, for my app it's ok to drop an old version
and just cram the new one in. If that's not OK, maybe just a comment at
the begining of the stored procedure saying
"Version:1.4.2" or something?
Hmm I guess I have some research to do...
 
(e-mail address removed) wrote in
Ahh! all good questions! These issues have not actually been resolved
(this tool was just started last Friday! ;)).
But yes, I will have to deal with these some time soon. I'm not too
worried about SP versioning, for my app it's ok to drop an old version
and just cram the new one in. If that's not OK, maybe just a comment
at the begining of the stored procedure saying
"Version:1.4.2" or something?
Click to expand...

Ya I'm thinking of tagging my SPs - perhaps wrapping the SP in a XML
container.

Personally I don't like SPs - but some of our integrators are not
programmers... and SP scripting is the closest they'll come to programming
with an API :S
 
Back
Top