|Faketable fails when table uses a uddt as a colum type||rkr||12/11/12 3:20 AM|
There seems to be a problem when trying to fake a table that contains columns whose type is a user defined data type.
The test fails with the message: "COLLATE clause cannot be used on user-defined data types".
Here is some code to reproduce:
EXEC tSQLt.NewTestClass 'fake_tables_with_uddt';
CREATE TYPE fake_tables_with_uddt.some_type FROM NVARCHAR(20)
CREATE TABLE fake_tables_with_uddt.some_table (some_column fake_tables_with_uddt.some_type)
CREATE PROCEDURE fake_tables_with_uddt.test_can_fake_table_with_uddt_column
EXEC tSQLt.FakeTable 'fake_tables_with_uddt.some_table';
EXEC tSQLt.RunTestClass 'fake_tables_with_uddt';
DROP TABLE fake_tables_with_uddt.some_table;
DROP TYPE fake_tables_with_uddt.some_type;
EXEC tSQLt.DropClass 'fake_tables_with_uddt';
As a little extra: DropClass does not drop uddts. Thats why there are the extra drop statements for the table and the uddt just before the DropClass.
I assume that this only applys to uddts that with an underlying type of varchar, nvarchar and whatever else might have a collation.
Any plans on changing this behavior?
|Re: Faketable fails when table uses a uddt as a colum type||tSQLt||12/11/12 12:34 PM|
I just ran into this problem myself last week. It is on the backlog to be fixed, but there is no ETA yet.
|Re: Faketable fails when table uses a uddt as a colum type||Chris Francisco||1/2/14 11:07 AM|
FYI I ran into the same issue and was able to get around it by digging into the tSQLt code a bit. There's a Function named Private_GetFullTypeName
The last column returned by the function is named "Collation" which returns an empty string '' if the variable @CollationName is null. If you add "OR is_user_defined = 1" to the condition for the empty string I've been able to fake tables with user defined data types.
I haven't run into any weird side affects from this alteration but I'm no expert on the inner workings of tSQLt (or on tSQLt in general) so this may break functionality elsewhere.