Those have the form of TableNameInsertIgnore and have an insert statement in them. I can also tell you that there's one for each table that I have a data deployment package for. This should make sence I think.

They're not actually causing any trouble, but I think you should know.

This is the same package that I say I have trouble in depoloying at the topic "Exceptions while deploying a package".

This is the ONLY way that we will produce a stored procedure...I promise   If you go to the Stored Procedures and show the auto-generated sprocs, then you can determine which tables have those checkboxes set.  I know for a fact that if you are seeing autogenerated sprocs that you must have the CRUD sprocs checked somewhere.

There are no such autogenerated sprocs in the list of stored procedures in the DDT. The only autogenerated sprocs that I can see are the SFS sprocs. Perhaps I may sound a bit annoying, but I assure you this is not my intention. It is perhaps of my not so good English. I try to do my job, as you do, and I get into these problems, and you are the only ones I can ask. Please tell me if I overdo it. I don't have any reason of lying to you.

As for the stored procedures, here's a list of the stored procedures in my database after deploying the package.

You can see those *Ignore sprocs. Here's the contents of one of them.

ALTER PROCEDURE [dbo].[AreasInsertIgnore] @Area as
NVarChar(100) AS
IF NOT EXISTS(SELECT Area FROM Areas WHERE Area = @Area) BEGIN
INSERT INTO Areas (Area) VALUES (@Area) END

I have tryed to autogenerate sprocs for tables, and they all end up with _Insert, _Update, _Delete. Also they do not contain the EXISTS check as the one above. Here are the properties of the Areas table:

I don't know if the image is clear enough, but then again, I can tell when a checkbox is checked. The settings are the same for all those ten tables.  I don't use autogenerated sprocs, I write my own sprocs.

The only thing I can tell you about those *Ignore sprocs is that all of those tables they refere to have a data deployment package. Perhaps you use them to populate those tables with data.

As I told you, they don't cause me any trouble, I just thought you might want to know. I have no intention of getting on your nerves, and I am sorry if I ever did that.

George, I never intended to suggest that you were lying...I beleived you that those procs were in your database, but I was just informing you that these are not something that would be produced via that DDT.

Using the package file that you sent me earlier, I have deployed to my SQL Server database...and it did not produce those sprocs:

So I do not think that your sprocs are coming from the DDT...but rather are ending up in there some other way or are residue from some other type of script that may have been run outside of the DDT.

If you deploy your package file to a fresh server or use a different database name I would imagine that those sprocs would not appear as they did not show up in my database as evident from the screen shot above while using your package file that you had posted on another thread.  I would start fresh and deploy to a clean server or a new database name and see if these sprocs show up.  That would be the first thing that I would look at.