Is it compulsory to have atleast one Unique per table in Sql Server2000?

Short answer: No — SQL Server 2000 does not force every table to have a UNIQUE or PRIMARY KEY. @deeraj is correct. A table without any unique constraint is perfectly legal; inserts fail only when some other rule, constraint, permission or client limitation prevents the operation. See Microsoft documentation on primary keys and unique constraints for background: Primary keys and unique constraints.

Diagnose by isolating server vs client behavior. Run an explicit INSERT in Query Analyzer (or osql) and capture the exact error text. Inspect the table DDL and constraints — @pclfw’s idea to generate the CREATE script is exactly the right next step. Helpful server-side checks:

EXEC sp_help 'dbo.YourTable';
EXEC sp_helpconstraint 'dbo.YourTable';
SELECT name FROM sysobjects WHERE xtype='TR' AND parent_obj = OBJECT_ID('dbo.YourTable');

If the INSERT works in Query Analyzer but fails when using Enterprise Manager, an ODBC driver, or an ADO Recordset, it’s likely a client-side limitation: many GUI editors and some cursor/lock types require a unique key to build updatable recordsets. Adding a primary key or unique index fixes that for the client, and is good practice for row identity (see Primary keys).

If the INSERT fails in Query Analyzer too, look for server-side causes: NOT NULL columns without default values, CHECK or FOREIGN KEY violations, triggers that roll back inserts, permission or database read-only issues. Capturing the exact server error and the table DDL (use Generate SQL or the sp_help output above) is the reliable way to identify the true cause. @jwshepherd’s prompt to confirm whether a row insert (not DDL) was intended is also important when interpreting the failure.