On SQL Server, you have the following options:

• Deny object permissions. For example: DENY DELETE ON OBJECT::dbo.Customer TO db_datawriter;
• Raise an error in a trigger: CREATE TRIGGER nodelete1 ON dbo.Customer INSTEAD OF DELETE AS RAISERROR('You can''t delete from this table', 16, 10)
• Rely on referential integrity without cascading updates/deletes. Note that this will only prevent deletion of a customer, if the customer has at least 1 order.

In my honest opinion, however, I think that this should be solved at the application level and not the database level. Even if using the techniques above, what would prevent someone from simply removing the trigger or grant the necessary permissions before DELETE'ing the records? Or simply dropping the entire table?

If you don't want your users to delete records from a table, simply make sure that your application does not allow them to do that. Anyone working directly with the database should know that issuing a DELETE statement could be dangerous - especially if you don't have a backup.

If the table is accessed only through an application, you can use a soft delete, to do that add a column to the table, for example IsDeleted , and check it in the software to see whether the row is live or deleted.

If the final users can access the DB, you can to change his/her login or group permission to remove the delete grant on that table.

i do it with a simple trigger on each table that i want disable delete

Create Trigger [dbo].[RollBackDelete]
     ON [dbo].[Your Table Name]
INSTEAD OF DELETE 
AS
BEGIN
ROLLBACK;
END

ofcourse if you have any key with cascade operation on delete or update it can not be work and you should set it to "No Action"

i hope this be be useful