>>>>>>>I found the solution. Instead of using .ToShortDateString() on the ASP.NET side, I have to use a specific format:
>>>>>>>
>>>>>>>

>>>>>>>TargetDate.Date.ToString("yyyy-MM-dd HH:mm:ss");
>>>>>>>

>>>>>>>
>>>>>>>The above works for both the American date and the British Date.
>>>>>>
>>>>>>This is the format I have been saying since the beginning :) So you had access to the code, good.
>>>>>
>>>>>Yes, I wrote all the bad code :) I just didn't know how to set the string to the correct format. As I said, it was working for years with the .ToShortDateString() (here in is the USA). The customer in Europe exposed the "hole" in my code and I had to change it.
>>>>>Thank you for bringing it up to my attention.
>>>>
>>>>BTW since you are not really using time:
>>>>
>>>>

TargetDate.Date.ToString("yyyyMMdd");

>>>>
>>>>Note: No dash or other separator in between. Otherwise it fails under some versions with specific language settings (like TURKISH).
>>>
>>>You maybe right. But in my SQL Server SP code I am converting this string to a DateTime type (code I wrote in another message). So, I am concerned that if I don't add the time portion (which is not used), the value of the variable will be set correctly. So far, in my testing, the string with dashes and the time work.
>>>But if it starts causing problems, I will change it.
>>
>>OK I repeat, don't add separators. Time part is up to you. I wouldn't wait for it to cause troubles when there is a safe version exists.
>
>When I remove the separators (that is, using "yyyyMMdd"), I get error again. When I have separators, no error.
>I think it all comes back to how I use this field in the SQL server SP.

Removing separators you get error just because you are forcing the result to be char(10), right?