dependencies with fully qualified view name

bruinsevebruinseve Posts: 6
edited July 15, 2005 5:34AM in SQL Toolkit Previous Versions
we are using the toolkit to generate differential scripts. If a vew contains a fully qualified view or table name the dependency is not recognized by red gate and objects will be scripted out of order. If I remove the database name from the object the dependency will be recognized.

For Example:
within database DB1
create View testview as
select * from DB1.dbo.mytable

will not recognize the dependency and may try to create the view before the tabl while

create view testview as
select * from dbo.mytable

will recognize the dependency.
Is there as setting or something I'm missing which will fix this? I realize the dependency wouldn't be necessary if the object were in a different database but shouldn't it be picked up for a fully qualified object in this database? I'm using version of the sql compare dll



  • Brian DonahueBrian Donahue Posts: 6,590 New member
    Hello Steve,

    I recall that this has happened before and I don't think there was ever a fix for it. I'm certain that there aren't any settings that you can change to get it to work. It's just a matter of recognizing fully-qualified objects like this one.

    Can I ask around and get back to you about this tomorrow?
  • Any info you can give me would be appreciated.
  • Brian DonahueBrian Donahue Posts: 6,590 New member

    I'd done a small test to see if it works by creating a view that depends on a table that has schema differences between databases. The view selected columns from the table in a fully-qualified fashion. When I specify the columns from the table, the dependencies work.

    When I change the view to 'SELECT * from TestDB1.dbo.VIEW1', then the dependent table is not scripted with the view. I think this sort of makes sense, since any changes in the underlying table would be irrelevant to the view since it selects all columns anyway.

    Do your dependencies work if you specify the columns in your view's SELECT query?
  • That was just an example of the difference and not the actual view in question. The columns are specified in the actual view. Both the view and the table were already set to be synced. The problem is that if the table name is fully qualified it will script the view first and then the table causing the script to fail. If I don't fully qualify the name it will realize that the table needs to be scripted first
  • Brian DonahueBrian Donahue Posts: 6,590 New member
    Would it be possible for you to use Enterprise Manager to script the views and the underlying tables from this database and send it on down to [email protected]?

This discussion has been closed.