erR? TSD03006. Doh!

  • Article

I’m often skeptical when I read things like this that make absolute statements:

To resolve this problem, upgrade to Microsoft Visual Studio Team System 2008 Database Edition GDR R2.

FIX: When you access a table source in a referenced project by using an alias in VSTS 2008 Database Edition GDR, if you refer to the table source by using a three-part or four-part name, you receive TSD03006 errors or TSD04151 warnings

In my particular case for a new project where I have imported schemas created by Someone Else™ who overzealously fully qualified all the object names in every view definition and stored procedure in eight out of 12 databases in the solution (even when the views reference objects in the same database)... it’s NOT true.

Grrr.

Visual Studio beats me because she loves me. *pout*

Not sure how I missed GDR R2. That’s fun to say. GDR R2. Like magma. Magma is a funny word. GDR R2. Or maybe I left a note2self somewhere that I forgot to read. Huh.

Anyway, I got around to downloading it:

Download Details: Microsoft® Visual Studio Team System 2008 Database Edition GDR R2

But it didn’t magically fix all the errors that GDR reported for tri-part names for me. The following valid object definitions are reported as build errors:

  • View definitions that contain a three part name that includes the database containing the object. The Add Database Reference interface will not allow me to add a self-reference, so the fix seems to be to remove the database name. Editing ~300 object script files.
  • View definitions that contain a three part name in which the referenced database (which has a valid database reference in the project) name is “quoted” in square brackets. Removing the brackets allows Data Dude to resolve the reference correctly. Yay! Only ~200 object script files to edit (which incidentally were EXPORTED BY DATA DUDE in the first place).
  • [Edit] Database reference names are case-sensitive and must match the referenced database project name exactly, even in case-insensitive database projects. Yeah, yeah. Make them match in case and everything’s fine.

It’s apparently too much to expect full parity with the database engine parser or that there’s a way to flag specific errors generated from otherwise valid T-SQL to be ignored without a blanket ignore for an entire error code @ the project level... because some day somebody else might actually produce a bug in that class that I want the build to catch. (Nah, I’d never do that myself. *wink* )

The oversight of quoted identifiers for the database reference name is [censored], but, yes, I agree that self-references are silly in views for the database name (I can imagine several scenarios about how they happened, though), but I’ve 774 more errors in this solution to clean up before I can check in all the schemas that I just imported into Data Dude.

#@%&!!!