Ghost table in MSysObjects

[KitaYama]

Sorry for the length of the question:

I have a script that refreshes (or adds links to) all tables (156) in a SQL server database.
Recently this script throws an error on tblSupplier_Type.
If the script try to refresh this table, I receive an error saying tblSupplier_Type doesn't exist.
If the script try to add a new linked table, I receive an error saying tblSupplier_Type already exists.

With Show hidden and system objects ticked, searching for this table in navigation bar doesn't show anything.
But running this query:

SELECT Name, Type, Database FROM MSysObjects WHERE Name = 'tblSupplier_Type';

shows this:

OK. I have no time to waste. I added a new database, imported all objects (everything except the tables) and tried to fix the references. But to my surprise, the ADO reference on two databases reads different:

Left image: Previous Database.............................................................................Right image: new Database

.....

Now my questions:

1. Why I have a ghost table in MSysObjects? How is it possible? The database is not corrupt. I have had this problem for at least two months, and all the while the database is acting perfect. Not even a single sign of corruption through our whole domain.
2. Why a brand new database points to a different version (older) of a library, while a 10 years old db has a newer version.

Notes:
Both databases are created on the same PC. Both images belongs to the same PC.
Both databases show available references to ADO 2.0, 2.1, 2.5, 2.6, 2.7 & 2.8. The only difference is one shows 6.0 the other shows 6.1

Sorry again for the length and thanks for any kind of insight on this.

 

[KitaYama]

If the script try to refresh this table, I receive an error saying tblSupplier_Type doesn't exist.
If the script try to add a new linked table, I receive an error saying tblSupplier_Type already exists.

I should have explained better. The above is occured in bellow section:

If DCount("[Name]", "MSysObjects", "[Name] = '" & tbl & "'") = 1 Then
    db.TableDefs(tbl).Connect = stConnect
    db.TableDefs(tbl).RefreshLink
Else
    AddLinkedTable tbl, stConnect
End If

 

[The_Doc_Man]

I note that the two libraries are different in an odd way. The 6.1 (left side) reference is MSADO15.DLL but the 6.0 (right side) reference is MSADO60.TLB - so the left side is a dynamic link library (which I would have expected for the ADO library) but the right side is a text library (or maybe a type library?) - and I note that the .TLB isn't checked.

So far as I can research this, ADO15.DLL would have come from Office 2013. MSADO 6.0 is a Windows 7-related file from about 2003 (?). And there are notes online - more than one article, in fact - about MSADO60.TLB being notoriously absent for Win7 or Win Server 2003, such that you have to search for a place to download it. At the moment, can you even check-mark that reference or does it say "Missing" for the file?

As to your other problem, I don't know how it would get this way to show up as a table, but the object type (in mSysObjects) for code -32768 is a Form according to this reference:

Object type codes in Access

Codes for the objects in the Access mSysObjects table.

www.alvechurchdata.co.uk

This is clearly from a very old version of Access (see the page name!) because if you look up object types in a more modern version, forms are code 2, not -32768. The page in question does not appear to have been well-maintained, but it is the only thing I found with that code. The codes you would find now using Object Explorer (from a VBA page) do not use the value.

The contradictory nature of that finding leaves me unsure where to go with this research. Colin (@isladogs) might have more information about these older files, but I don't have any old versions available to me to directly inquire further.

 

[KitaYama]

At the moment, can you even check-mark that reference or does it say "Missing" for the file?

Yes I can tick it. It's unticked because while I tried to take the screenshot, I clicked it to highlight it and it got unchecked.
If I tick the checkbox, the db compiles and I have no problem.

Should I re-register ADO15.DLL?

This is clearly from a very old version of Access (see the page name!) because if you look up object types in a more modern version, forms are code 2, not -32768.

My research shows that -32768 means orphaned table. That's OK for me. Maybe for some reasons, the linked table has been deleted once and the MSysObject table has not been updated.
Will it be OK if I delete it manually? (The table seems to be locked for deleting, but I saw some suggestions on how to enable delete)

All my questions are for understanding better. I have valid backups and no problem at all.
I just wanted to understand how a table may be orphaned and why two different references for ADO.

Thanks for your time and researching. I didn't expect that.

 

[isladogs]

Normally the data in MSysObjects is very reliable but things can go wrong.
Tables, queries and macros are first flagged as ~TMPCLP... rather than deleted . . . and are only deleted when the database is next closed.
Forms, reports and modules should be deleted immediately...but even that can go wrong occasionally.

Phantom objects can remain in MSysObjects if the database crashes after an object is 'deleted'

Suggest you read my article below for a detailed explanation both of the possible causes and a solution for each

Remove deleted objects

This article explains how to remove 'legacy' deleted objects from the read only MSysObjects system table if you have problems.

www.isladogs.co.uk

Also, to confirm -32768 is a form, not a table (orphaned or otherwise)

BTW - I suggest you reorder your references with the default 4 references at the top

 

[KitaYama]

BTW - I suggest you reorder your references with the default 4 references at the top

Done.

and thanks for the correction on -32768.
Reading your article now.