What are the challenges you face when working across database platforms? Take the survey

Phantom Unresolved Internal References

cklckl Posts: 3
edited March 27, 2008 8:20AM in SQL Dependency Tracker
I am getting some Unresolved Internal References on a couple of views, but when I go to the database schema in Management Studio (SMS), the object referred to is not mentioned. In each case the unresolved internal reference is a likely looking name (i.e. not random) but I cannot see where the view references the object. If I use SMS to list objects on which the view depends the phantom object is not listed.

Has anyone else seen this problem?

I am using SQL Server 2005 SP2, and Dependency Tracker V2.40.75.0



  • Options
    Some more information:

    If I select Show SQL Script on the shortcut menu for the view, the first lines are

    -- View
    CREATE VIEW [dbo].[MyView]

    but the view is actually called rpt_MyView. If I check this in SMS, the view is correctly called rpt_MyView, and if I script it in SMS the script contains rpt_MyView. Only Dependency Tracker seems to think the script should call it MyView. If I look at he name of the object in the Objects in Project window, it is called rpt_MyView.

    If I rename the view to MyView in SMS and rerun the whole thing, Dependency Tracker is happy. If I rename it back Dependency Tracker gets upset again.

    What on earth is going on? Anyone?


  • Options
    Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Charles,

    It looks as though you are suffering from this SQL Compare issue. Since Dependency Tracker uses version 5.3 of the SQL Compare Engine logic, the problem will not be worked around until Dependency Tracker is built using the new components, which should happen in a few weeks.

    To identify whether or not this is the issue, you may run the following query in Management Studio:
    select c.text from syscomments c inner join sysobjects o on o.id=c.id where o.name='rpt_MyView'
    This should show whether there is a mismatch between the name of the view in the metadata and the actual definition that created the view (the latter being the one Dependency Tracker uses).

    The only workaround at this time would be to drop and re-create the view with the proper name.
Sign In or Register to comment.