Я работаю в ASP.NET в качестве внешнего интерфейса и SQL Server 2012 в качестве внутреннего интерфейса. В ASP.NET пользователь вводит дату в 3 текстовых поля в формате ДД / ММ / ГГГГ.
Теперь я объединил эти значения текстового поля в строку. В SQL Server я хочу сохранить эту дату в столбце DOB
с типом данных DATE
.
Ниже представлена объединенная строка в ASP.net
string strDOB = txtYY.Text + "/" + txtMM.Text + "/" + txtDD.Text;
Как мне теперь сохранить этот strDOB
в SQL Server?
Если предпочтение отдается ответу Дэмиена, вы можете отметить его как таковой. Часть вопросов и ответов A - это источник жизненной силы SO.
Попробуй это:
UPDATE [Table] SET [Column] = '' + strDOB + ''
Однако будьте осторожны ... это не было продезинфицировано для защиты от внедрения SQL. Я только продемонстрировал прямой ответ на ваш вопрос, не более того.
Рекомендуется никогда не объединять непроверенные вводимые пользователем данные и сохранять результат в столбце. Методы предотвращения этого выходят за рамки данного раздела вопросов и ответов, но их легко обнаружить с минимальным объемом поиска.
--РЕДАКТИРОВАТЬ--
Я полагаюсь на ответ Дэмиена по этому поводу. Я согласен с его предложениями по синтаксису.
Если вы знаете, что это плохая практика и уязвимость для SQL-инъекций (на самом деле это недопустимо), то не следует добавлять это в качестве ответа, не так ли?
Но это «Пусть SQL Server выполнит преобразование по умолчанию из строки в дату, и надеяться его интерпретация совпадает с вашей». Не идеально.
@Schadensbegrenzer ~ Потому что это выходит за рамки вопросов и ответов.
date
, вы должны как минимум использовать явныйCONVERT
, указав параметр стиль, который, как вы знаете, соответствует передаваемой строке.
@Schadensbegrenzer ~ Я не знаю, проголосовали ли вы против, но если это так, я ценю сопроводительный комментарий. Как вы, возможно, заметили в другом месте, я веду кампанию против тех, кто отказывается голосовать. Я не против того, чтобы проголосовать против, так как я против БЕСШУМНОГО отрицательного голоса.
@Damien_The_Unbeliever ~ Понятно, спасибо. Я пока точно не знаю, как это сделать, поэтому перед редактированием мне придется провести небольшое исследование. Также: я не знаю, проголосовали ли вы против, но если да, то я ценю сопроводительный комментарий. Как вы, возможно, заметили в другом месте, я веду кампанию против тех, кто отказывается голосовать. Я не против того, чтобы проголосовать против, так как я против БЕСШУМНОГО отрицательного голоса.
@InteXX Да, я проголосовал против. И я никоим образом не хотел подвергать сомнению вашу квалификацию. Я также согласен с тем, что это может выходить за рамки вопросов и ответов, однако Stack Overflow также является ресурсом для примеров кода, и люди приходят сюда из Google и других мест. Так что я надеюсь, что отрицательный голос воспринимается как утверждение «пожалуйста, не делайте этого».
Прекратите использовать струны. Помимо рекомендаций в комментариях по использованию специального элемента управления для выбора, следующий лучший совет - разобрать эти строки на целые числа (кратко), затем построить объект DateTime
из этого, а затем не позволяйте преобразовать его обратно в строку. Когда люди допускают дополнительное преобразование строки / даты, возникают проблемы с форматированием представлять. Итак, получите значение:
var year = Int32.Parse(txtYY.Text);
var month = Int32.Parse(txtMM.Text);
var day = Int32.Parse(txtDD.Text);
var dob = new DateTime(year,month,day);
А затем передайте его в SQL Server:
var cmd = new SqlCommand(...);
cmd.Parameters.Add("@DOB",SqlDbType.Date).Value = dob;
И убедитесь, что ваш запрос использует параметр @DOB
везде, где вы хотите использовать это значение.
Почему бы не использовать средство выбора даты в приложении вместо того, чтобы полагаться на то, что пользователь введет действительную строку даты. Если они введут строку
'07/01/2018'
, как узнать, 07 января это или 1 июня? И нет, ответ не «потому что пользователь всегда будет вводить в формате дд / ММ / гггг». Пользователи - непостоянные и непредсказуемые существа, и никогда / редко можно доверять их постоянству.