For those interested, I believe this is a bug.Take a look at the code for the INFORMATION_SCHEMA.TABLE_CONSTRAINTS view in SQL7: --Identifies table constraints owned by current userscreate view INFORMATION_SCHEMA.TABLE_CONSTRAINTS as select db_name() as CONSTRAINT_CATALOG ,user_name(c_obj.uid) as CONSTRAINT_SCHEMA ,c_obj.name as CONSTRAINT_NAME ,db_name() as TABLE_CATALOG ,user_name(t_obj.uid) as TABLE_SCHEMA ,t_obj.name as TABLE_NAME ,case c_obj.xtype when 'C' then 'CHECK' when 'UQ' then 'UNIQUE' when 'PK' then 'PRIMARY KEY' when 'F' then 'FOREIGN KEY' end as CONSTRAINT_TYPE ,'NO' as IS_DEFERRABLE ,'NO' as INITIALLY_DEFERREDfrom sysobjects c_obj ,sysobjects t_objwhere c_obj.uid = user_id() and t_obj.id = c_obj.parent_obj and c_obj.xtype in ('C' ,'UQ' ,'PK' ,'F') If I query the sysobjects table, the userid is set to 1 (which is dbo user) on all the constraints.When I log in as a user (even in the db_owner role) the user_id() function does not return 1. Therefore the INFORMATION_SCHEMA.TABLE_CONSTRAINTS view retuns zero records.I looked at the same view's code in SQL2000 and the call to user_id() has been replaced with a call to permissions() which makes more sense, and not surprisingly, works properly.Still, I am stuck on SQL 7 so it looks like I am screwed for using the INFORMATION_SCHEMA.TABLE_CONSTRAINTS view.----Nancy Davolio: Best looking chick at Northwind 1992-2000