"Cannot find data type" restoring a SQL Server 2014 backup on SQL Server 2008 R2
Actually, tCompressedBinary sounds like it might be a true UDT (a user-defined type implemented using CLR) rather than a UDDT (a user-defined data type, which are just aliases for other types created with syntax like CREATE TYPE creditcardno FROM CHAR(11) NOT NULL;

See the answers to https://stackoverflow.com/questions/35494575/sql-server-udt-versus-uddt for more information and links to MS documentation.

If tCompressed is a UDT then it won't be included in the database scripts you have generated. You will need to install and activate that CLR module in the new SQL Server instance before you can run the scripts to build this schema. Otherwise go with my original answer, below.

If you really can't do that (you don't have permission to turn on CLR on the new instance, the module is a 3rd party one that doesn't support 2008r2 at all, etc.) then you might get away with replacing all references to the type in column and parameter definitions with with what-ever type the application code is compatible with (VARBINARY(MAX) would be my first guess).



If you are using 2008r2 Enterprise Edition then compression is supported so that would not be the problem. In that case, check the definition of the user-defined type tCompressedBinary. Are there errors when it is created? Or is it present in the wrong order (defined in the scripts after it is first used)?

If you are using an edition other then Enterprise, then search the scripts and remove all references to [WITH] COMPRESSION. Of course, there may be other compatibility issues once you have removed all the compression directives which will become apparent once you've tidied up this one.