Phantom Unresolved Internal References

Visualizes SQL Server object dependencies.

Phantom Unresolved Internal References

Postby ckl » Mon Feb 04, 2008 6:21 pm

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

Posts: 2
Joined: Mon Feb 04, 2008 6:13 pm

Phantom Unresolved Internal References (more info)

Postby ckl » Tue Feb 05, 2008 2:00 am

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?


Posts: 2
Joined: Mon Feb 04, 2008 6:13 pm

Postby Brian Donahue » Thu Mar 27, 2008 12:20 pm

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:
Code: Select all
select c.text from syscomments c inner join sysobjects o on where'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.
Brian Donahue
Posts: 6590
Joined: Mon Aug 23, 2004 9:48 am

Return to SQL Dependency Tracker 2

Who is online

Users browsing this forum: No registered users and 0 guests