Guys,

I have a situation where I have a couple of stored procs that refer to a linked server. Now, at customer deployment time, my linked server name, isn't likely to be their linked server name. I have a solution to overcome this, not pretty but does work.

What I would like to know is, can I flag a stored proc in any way so as it doesn't get packaged up? If this isn't possible any chance of getting it on the list of enhancements? either with a checkbox, saying Do not deploy OR a group of procs that you just put the proc into the group that you don't want to deploy.

I guess this might sound a little daft, but I don't want to remove the stored procs from the structure, mainly because over time I will likely lose them.

thanks in advance

Geoff

Sorry this question is in wrong area.

G.

I don't know if this can be done. However, pre/post scripts might provide some way to work around this. I'll be watching this, as I have a similar need, were there is a view using a linked server in production, but not on my dev or test machines.



One thought would be to include a post script to add sproc, rather than having it in DDT. Then you could swap out the sproc between your local and your client installs. If you think of something else, keep us updated!

Hi Greg,

Well what I have done up to now, is create a table of machines that can have data imported from. These could be linked servers. In the DDT I have put a 'dummy' proc just so the proc gets downloaded and later I use a routine from my client application that as the user views each linked server record, they can  create the specific stored proc from a text file template that I bundle with the client application. Using replace to find a text marker works fine and it replaces the text marker with the server name and database name in the viewed record. 

For this to work, all I need is for the proc to exist in the SQL Server DB, it doesn't matter what it does initially as it will never be used like that. The text file template I have is encrypted, and only ever decrypted in memory just for the sake of security. The text file gets read in, decrypted, markers replaced, then the proc is executed as an alter procedure. The original text file template remains on disk in its encrypted form.

It does the job, it would be nice to be able to have procs though that you could flag as not to be packaged. I don't know about everyone else, over time I get better ideas and rather than just replace old code I like to keep 'just in case' and create new. It would be good if those procs were just kept in the ddt profile.

best

Geoff

Like Greg mentioned, the pre and post deployment scripts are good candidates for this.  However, your request to have one excluded is not a bad idea.  I will add this to the list to be considered.