I understand. Since I started using the DDT I am binding the schema to the DDT. Later on I will try to see if this can be duplicated by simply create a table, generate the partial, then change the table name in the DDT and regenerate. Will let you know the results later today.

Edhy Rijo

Edhy, this sounds very suspect since this is a feature that has always been supported by the framework.  When the BOM rebuilds the partial, it will rename the BO properties as well within the designer file.  If you are binding the schema to an SQL structure instead of the DDT (which is probably not likley) then I could see this happening.  Otherwise, I would be curious to see if this is reproducable on your side.

Hi Trent,

I am familiar with the process you outlined here, and for the record, that is not what happened. I did all steps above and the names of the SPs where with the correct table name, in fact I followed your suggestion of not putting the SP names at the BO level and let the BO itself figured out the SP names, it was the name of the table in the BO.designer file that was left with the old table name and was not updated by the BOM.

Edhy Rijo

No, it was your stored procedures that needed to be updated.  When you change the name of a table in the DDT and you are allowing it to automaticaly create the INSERT, UPDATE, or DELETE sprocs, you will have to manually reset those sprocs names.  Generally I will just go into the table properties of the table in the DDT, clear out the name of the sproc, then un-check and re-check the checkbox for each sprocs type and it will reset the name of the auto-generated sproc.

Most likely this is what happened in your case.  You still had the old sproc names.

I have a table named "CardImages", the BO was created using the name "bizCardImages", later on I renamed the table name to "CardImage" and the BO to "bizCardImage", everything was working fine until I tried to Insert a record, I got an error saying that the SP CardImages_Insert does not exist, so I went to the bizCardImage.Designer.vb and found out that the property TableName() was not updated with the new name of the table.



I had to manually fix the TableName() property to return the table new name and that fix the problem. Shouldn't the BOM take care of this property everytime a build partial is regenerated?

Edhy Rijo