I have been playing with the DDT with auto-generating stored procedures and have manged to somehow have two empty auto-generated stored procedures (see attached image).



So now I naturally get errors when deploying to server but I cannot seem to get rid of the empty stored procedures. The error I get when deploying indicates that these procedures belong to my Customers table and I ended up turning off the auto-generate in all of my table properties then generate the package and there the empty things are, smiling at me (actually they're probably at the giggling stage now ).



Am I missing something obvious, I have tried everything I can change, click or edit in the DDT but to no avail. Any help would be greatly appreciated.



Cheers,

Keith.

I should add that I found a recent thread on this very topic but I have no auto generate options checked but still have the empty [dbo].[] procedure.



I do know I was creating/deleting tables etc and I am wondering if somewhere along the way the empty procedures were created, then the original Customers table removed and a new one created. Is it possible this has given me the empty procedures that cannot be removed as the originating table is no longer there?



If this is the case I am looking at having to recreate the whole database, its not overly complicated but I'm fairly time poor at the moment, aren't we all!

Did you brinig in the localization packages through the deployment wizard? If so, go re-check the INSERT and UPDATE sprocs for the MessageItems and MessageLanguages tables. This is assuming you've already gone in and turn them off (if not, do that first.)

I did bring the messaging and localisation packages via the deployment wizard and I didn't check them for the auto sprocs.



Due to the 15 hour time difference I looked a bit closer at recreating the database from new and realised it was easier than I was imagining. (I guess you can always say you answer my questions before I even ask them!)



I renamed the existing database then created a new one and just imported all of my existing tables. I then, just for the exercise, created a seperate security database and opted for including messaging and localisation as compiled xml. The end result was after 30 minutes, I had to re-enter all field descriptions, I was deploying and received a completely new error, see attached, where one of the auto sprocs is not being created. If I turn off this sproc it deploys fine but as I don't create it and cannot edit it I don't know what is wrong.



Is this a possible future enhancement to import the description fields? Not a real issue as I realise importing is not generally an everyday occurrence.



Cheers,

Keith

Well it's good to hear we got past problem A, problem B is a bit of an odd one, isn't it?

Can you copy and paste the Sproc code that actually got deployed to your server. You can get to it through SQL Management Studio (they will be under the Programmability folder of your deployed database.) I'd like to see if something weird got put into the autogenerated code.

There is no ExerciseParts_Delete sproc code deployed to the server. I tried changing the concurrency option, removing then adding adding the sproc under a different name but it never gets deployed.



As the ExerciseParts table is only a small table I deleted it, removed it from the history then recreated it from scratch and bingo it now deploys fine. As the DDT is used by a large number of people all over the place I doubt the problem is from there. I am assuming that when I imported this table from the previous database it carried something in with it that deleting and recreating from scratch cleared up.



Thanks for the help and enjoy your weekend, its about 50 degrees fahrenheit and raining here so is only good for staying inside.



Cheers, Keith