Questions:
Are you trying to drop a table, drop a RI constraint, or get the delete to work?
Did you by any chance dump-n-load your database from a different server, or perhaps recently dropped the 'global' database from your dataserver?
-----------------
Background:
RI (foreign key => primary key) constraints are stored in the sysreferences table.
When you have cross database RI constraints the sysreferences table contains the dbname, dbid and table_id of the referencing and/or referenced tables.
When dumping-n-loading a database between dataservers, the DBA has to take care to address potential issues when any of the contents of sysreferences become corrupt (eg, dbname, dbid or table_id don't exist on target dataserver). [Unfortunately, addressing these types of issues is a bit convoluted as it depends on the type of issue(s) you run into.]
-----------------
Looking through the source code for sp_helpconstraint we can see ...
- the contraint name gets displayed as '*' when object_name(sysreferences.constrid,<other_db_id>) returns NULL; this can occur in the following scenarios:
- constraint does not exist in the <other_db_id> database
- constraint exists in the <other_db_id> database but has a different object id (constrid)
- <other_db_id> database does not exist on this dataserver
- the referencing object name, when said object resides in the <other_db_name> database, is displayed as <other_db_name>..<object_name>; in your case your display is showing 'global..<NULL>'; this can occur in the following scenarios:
- sysreferences.frgndbname='global' but there is not 'global' database in this dataserver
- the 'global' database does exist but sysreferences.constrid value does not exist in the global..sysobjects table (either contraint does not exist, or constraint exists but with different id)
-----------------
Fixing this issue is going to depend on which of the following applies ...
- the 'global' database does not exist in your dataserver
- the 'global' database does exist in your dataserver but there's no entry in the global..sysobjects table for id = <contrid>/<tableid>/<reftabid>
... and how you wish to fix the issue (eg, drop this entry from the local sysreferences table; load the global database; patch the local (and possibly global..) sysreferences tables).
You could start by trying to find the problematic records from the local sysreferences table. See the attached SQL script. [NOTE: I whipped this up without a problematic db to test against so we may need to come back and tweak the queries if it finds no issues in your db.]