If you actually want to ignore duplicate keys upon insert, then you'll need to use the IGNORE_DUP_KEY
index option in your index or unique constraint definition.
Here is the documentation on MSDN:
CREATE INDEX (Transact-SQL)
Example from that article (in section D. Using the IGNORE_DUP_KEY option):
CREATE TABLE #Test (C1 nvarchar(10), C2 nvarchar(50), C3 datetime);
GO
CREATE UNIQUE INDEX AK_Index ON #Test (C2)
WITH (IGNORE_DUP_KEY = ON);
GO
INSERT INTO #Test VALUES (N'OC', N'Ounces', GETDATE());
INSERT INTO #Test SELECT * FROM Production.UnitMeasure;
GO
SELECT COUNT(*)AS [Number of rows] FROM #Test;
GO
DROP TABLE #Test;
GO
For your table, this would be the command:
CREATE UNIQUE INDEX UNQ_CustomerMemo ON CustomerMemo (MemoID, CustomerID)
WITH (IGNORE_DUP_KEY = ON);
The disadvantage to using IGNORE_DUP_KEY
is that you lose visibility on what data is violating the unique constraint. Generally it is better to ensure the data is unique before inserting and then when you do have something fall through the cracks, you will get the error, along with the values that violated the unique constraint. This will allow for much easier troubleshooting of your insert statement. That being said, I make liberal use of this option when defining table variables because the scope is limited.
As for whether or not you should use a unique key or a unique index, see the following question on stack overflow:
Unique key vs. unique index on SQL Server 2008