MguerraTorres

The only thing that crosses my mind is that somehow, somewhere, this is ending up as a DATE datatype (which strips the time) then converting back to a DATETIME. Otherwise I'm completely dumbfounded.

Possible that there is a trigger on this table? This is crazy! (also, I'm unable to replicate this from my own environment. it just saves as a normal datetime.)

Another suggestion i'd have is to make a new variable within your procedure (DECLARE @DateNow DATETIME = GETDATE() or something) and use that in your UPDATE.

@charles.dawes what is the datatype of the column in question (password_reset_date)?

Can you confirm that the same exact table is being used, and that you are calling the same stored procedure that the app is calling? Ex: the app might have a different default schema or database.

can you confirm what happens if you change GETDATE() to CURRENT_TIMESTAMP? I'm thinking there's an odd datatype issue here.

@AaronBertrand is trying to enlighten you based on his experience (his rep speaks for itself and he's very well respected in the SQL Server community) and you're sitting there using phrases like "You're kidding, right?" Deploying a DB change is much less intrusive than a database-related application change when you've configured everything correctly on both ends. It just is.

@user441521 that's just not true. If you work your configurations right, you will simply have to deploy your stored proc when you change it, and any objects that are invalidated because of it. I have it set up this way in 8 or so apps. Most of the time I only have to reset IIS or whatever the app's service is. Unless I make a signature/spec change which is obviously more intrusive.

@Dominique: make it a stored procedure and have your application call it. Inline code in your app requires a deployment. If your app just calls a proc, you can modify it and not really have to re-deploy the app.

if that's the case, then create a "PROCESSED_Y_N" column and use that.

I assume you're using that "-1" value to confirm whether or not it's been "processed"

yikes, very odd. So what I would try first is to get rid of the INSERT into that IDENTITY column. You shouldn't be manually inserting values in there.

Sounds like the warning is a normal one unless you run the package as an admin. Not really something to worry about while developing.

Have you eliminated the four successful entries and looked at which entry could be the culprit?

Also, sometimes (oddly enough) it ends up requiring an ADO destination instead.

Which error?

Hello, sorry just didn't see the (1,1) in your table definition. Unfortunately other than that I can't really say what would be causing the random numbers to show up as the ID.

in your table definition, try IDENTITY(1,1) meaning start at 1 and increment by 1. Since you haven't defined this, it may be placing any random value there.

**Deleted, as you're already doing what I suggested here.

For NULL values, I would usually put oColumnName.Is_Null; as the output value when assigning in my C# code. It has been a while though. For the destination data type change, you need to go to your output properties and change it there. If you can't change it, you may need to delete the column and re-add it using the new datatype/length.