Error renaming a Column

[lprada]

When I crete this migration I get this error

        db.Tables["MaintenanceService.TaskInfo"].Columns["StoreProcedureName"].Rename("StoredProcedureName");

"Either the parameter @objname is ambiguous or the claimed @objtype(COUMN) is wrong."

[dradovic]

Which provider are you using? Can you show the SQL that is emitted?

[dradovic]

Closed due to insufficient information.

BTW, in the error message there is a typo: COUMM. I've searched the source code for this but did not find anything. Also note that we have integration tests running that test column renaming for all platforms.

So, if you can provide more information then I can help you.

[lprada]

sorry I was on Vacations. This is the command db.Tables["MaintenanceService.TaskInfo"].Columns["StoreProcedureName"].Rename("StoredProcedureName");, I am using SQL2008, If you tell me how to generate the SQL, I will send it to you.

[dradovic]

Please set the SQL trace level to verbose (using MigrationOptions.SetSqlTraceLevel). Then you will see the SQL that is generated. I wonder where this typo COUMN in the error message is coming from. Did you copy paste the error message or re-type it? And who is generating this message? Is it the Message of DbException?

[dradovic]

Probably the issue is the dot in the table name. Are you using several different owners within one SQL Server database?

[lprada]

Yes, I am using a lot of Schemas in SQL Server.

[dradovic]

Okay, the problem is that the SQL Server provider is issuing a

EXEC dbo.sp_rename @objname=N'[dbo].<tablename>.<oldColumname>', @newname=N'<newColumname>'

And in your case has a dot. Obviously [dbo] is wrong superfluous here. There are a couple of other places where [dbo] is used (mainly to be consistent with how SMO is handling these things) and for security.

As it stands, I have never thought of supporting SQL Server schemas. We simply don't use them because their are not portable. Mig# is about having portable migrations as you can read here: #29. On the other hand, I don't know if it would a great effort to do so. But honestly, I don't have the time to investigate this. For me this is a feature request: Add support for SQL Server schemas. Feel free to add such an issue. Then we can talk about that.

[dradovic]

This issue is obsoleted by #33.

[dradovic]

Thinking a little more about this, I come to the conclusion that dots in tablenames are not the problem since tablenames are escaped. This, of course, is not the same as using schemas. So have you created the table outside of Mig# using schemas, and now you are trying to access it via Mig#?

[lprada]

yes, this is how I Do it

//Create Table db.CreateTable("ExecutedTask") .WithPrimaryKeyColumn("TaskId", DbType.Int32) .WithNotNullableColumn("DateAdded", DbType.Int32) .WithNullableColumn("TaskInfoId", DbType.Int32) .WithNullableColumn("DateStarted", DbType.DateTime) .WithNotNullableColumn("Data", DbType.Binary) .WithNullableColumn("Info", DbType.Binary) .WithNullableColumn("Retries", DbType.Byte) .WithNullableColumn("DateExecuted", DbType.DateTime);

        //FK
        db.Tables["ExecutedTask"].AddForeignKeyTo("TaskInfo", "ExecutedTask_TaskInfoIdFK").Through("TaskInfoId", "TaskInfoId");
         db.Execute("ALTER SCHEMA MaintenanceService TRANSFER dbo.ExecutedTask");

[dradovic]

I see. In this case you really need #33 - explicit support for SQL Server schemas.