Home/ Questions/Q 6033577
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T05:30:11+00:00

I’m having a strange problem with SQL Server 2008, in which some datetime variables

  • 0

I’m having a strange problem with SQL Server 2008, in which some datetime variables within stored procedures are getting incorrect values (1754-01-01). Here is the background/context of the situation:

I’m working on an ASP.NET web application using the SqlMembershipProvider class. I use the out-of-box functionality for storing user data in the database, validating usernames/passwords, etc. Our application also has a custom e-signature implementation that requires authenticating the user with some additional information (mother’s maiden name, graduation year, etc.).

I do this authentication in two steps: first, I call Membership.ValidateUser(username, password) to do all the basic checks. If that succeeds, then I call a custom stored procedure to do the additional authentication. If this additional authentication fails, I would like to update the aspnet_Membership database table to record the failure — so that the user can get locked out after 3 failed authentication attempts in the same way that failed logins are handled in Membership.ValidateUser.

I did some research and determined that the Membership.ValidateUser method records failed logins and locks out the user account by calling the aspnet_Membership_UpdateUserInfo stored procedure. So I decided to just call this stored procedure from within my custom authentication stored procedure as needed, in order to increment the FailedPasswordAttemptCount column, IsLockedOut, etc.

The problem is that when I invoke this stored procedure directly, the stored procedure is unable to retrieve the correct datetime value (FailedPasswordAttemptWindowStart) from the aspnet_Membership table in order to correctly increment the FailedPasswordAttemptCount. The UpdateUserInfo stored procedure declares a local variable and does a select statement to retrieve this datetime value from the membership table into the local varable. The datetime value it retrieves is always 1754-01-01 00:00:00.000, regardless of what value is stored in the table.

I am trying to figure out why I cannot retrieve the correct datetime value from this database table within this stored procedure. Here is what I have tried:

Incorrect datetime value is retrieved when:

  • invoke aspnet_Membership_UpdateUserInfo from my custom stored procedure, which in turn is invoked from C# using Linq to SQL
  • invoke aspnet_Membership_UpdateUserInfo directly from my application using Linq to SQL
  • invoke a custom stored procedure that has the same code as UpdateUserInfo from my stored procedure, or directly from C#

Correct datetime value is retrieved when:

  • Invoking aspnet_Membership_UpdateUserInfo directly from SQL Server Management Studio
  • Invoking my custom stored procedure directly from SSMS, which in turn invokes aspnet_Membership_UpdateUserInfo
  • aspnet_Membership_UpdateUserInfo is invoked via the Membership.ValidateUser method

Has anyone seen a problem like this, where a stored procedure selects a value of 1754-01-01 from a db table instead of the correct value? I’d really like to have an understanding of why this is happening, but would be open to a workaround to somehow avoid this issue entirely. All I really need is a way to track failed username+password and failed custom authentication attempts in the same way, so that the user gets locked out after too many failures.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Marking as answered. I was using Membership.ValidateUser to do the initial check of the user’s password, etc., and then immediately after that calling my stored procedure to do the initial authentication checks and the subsequent UpdateUserInfo call. When testing the use case of “correct password, incorrect additional authentication info”, I forgot that the initial ValidateUser call ends up resetting the FailedPasswordAttemptCount and FailedPassswordAttemptWindowStart values in the database. So the datetime values really were correctly being set to 1754-01-01, the stored procedure I was calling was not retrieving incorrect data.

    I fixed this by removing my call to ValidateUser for the special authentication scenario, and instead manually hashed the user’s password and sent that to my custom stored procedure, so that all the authentication took place in one step with one subsequent call to the UpdateUserInfo procedure.

    • 0