Finally, I got it running and capture the result. The changes are in bold characters.

BEGIN

BEGIN TRY

...

I think I start to have a glimpse of what's going on. I created a smaller SP for testing and the begin try - end try block looks like this:

BEGIN

BEGIN...

Well, yes, that's a good idea. However, first I should start with a Visual Studio Ent. debugger, which I don't have.

MySQL is the last place where I'd try to fix these dates.

How can you fix invalid dates like 2008-02-30 or 2005-06-31 in there? MySQL accepts those dates with a warning....

Yup, everything turned out fine.

Thanks a bunch for the support.

Oops, now it's really working IF I try to add the unique constraint on date_created, as well. That's much better.

I just tested your whole scenario and it turns out that it doesn't quite work as you expected.

I have the table:

CREATE TABLE [dbo].[testumasii](

[id] [int] IDENTITY(1,1) NOT NULL,

[date_created] [smalldatetime] NOT NULL,

...

What you're saying over there doesn't work at all for the intended purpose - smalldatetime/datetime/bigdatetime uniqueness enforcement.

Yes, indeed, I have the unique index on date_created (smalldatetime NOT NULL)...

That could work, I see only one problem: if I have one transaction with multiple inserts, how is this going to behave?

To my understanding, there's no handling in triggers using...