Выполнение хранимых процедур с параметрами даты: объект команды vs объект подключения

Question

При предоставлении дат для хранимой процедуры через параметр я немного запутался в том, какой формат использовать для дат. Мой оригинальный синтаксис VBA использовал объект ADO Connection для выполнения хранимой процедуры:

Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText)

Это прекрасно работает для меня, используя синтаксис даты yyyy-mm-dd, но когда другой пользователь выполняет код, он получает сообщение об ошибке: 13 «Несовпадение типов».

После некоторых экспериментов я обнаружил, что указание даты в формате dd/mm/yyyy исправляет эту ошибку для пользователя, но теперь выдает ошибку!

Выполнение хранимой процедуры с использованием объекта команды с параметрами работает независимо от формата даты (я предполагаю, что ADO заботится о форматировании за кулисами). Я думал, что использование формата yyyy-mm-dd будет работать универсально с SQL Server?

Я также озадачен тем, почему эта проблема, кажется, зависит от пользователя? Я заметил, что моим языком по умолчанию на SQL Server является «английский», тогда как язык другого пользователя по умолчанию «британский английский», может ли это вызвать проблему?

Я использую ADO 2.8 с Access 2003 и SQL Server 2000, вход в SQL Server осуществляется через встроенную систему безопасности Windows.

Answer 1

Будьте осторожны, и не верьте, что ADO решает проблему. Универсальный формат даты SQL - «ГГГГММДД», в то время как на SQL и ACCESS влияют региональные настройки машины в том, как они отображают даты и преобразуют их в символьные строки.

Не забывайте, что разделитель даты # в Access, а в SQL

Мой лучший совет - систематически преобразовывать ваш Access # MM-DD-YYYY # (или аналогичный) в «YYYYMMDD» перед отправкой инструкции на ваш сервер. Вы можете создать небольшую функцию, такую ​​как:

Public function SQLdateFormat(x_date) as string

SQLDateFormat = _
   trim(str(datePart("yyyy",x_date))) & _
   right(str(datePart("m",date)),2) & _
   right(str(datePart("d",date)),2)

   ''be carefull, you might get something like '2008 9 3'
SQLDateFormat = replace(functionSQLDateFormat," ","0")
   '' you will have the expected '20080903'

End function

Если вы не создадите строку INSERT / UPDATE программным способом перед отправкой на сервер, я посоветую вам переключить региональные настройки всех машин на региональные настройки машины, на которой установлен SQL. Возможно, вам также придется проверить, существует ли определенный формат даты на вашем сервере SQL (я не уверен). Персонально, я решил этот тип проблем локализации (это также происходит, когда кома используется в качестве десятичного разделителя на французском языке) или проблемы специфических символов SQL (когда кавычки или двойные кавычки в строке) путем отступления инструкций SQL перед отправкой их в сервер.

Answer 2

Вы можете использовать функцию Date () для возврата универсальной даты на основе настроек даты и времени аппарата. Настройки региона на компьютере будут определять, как он будет отформатирован на стороне клиента. Если вы оставите поле более строгим, чем поле DateTime, то параметры региона очистки могут отформатировать дату.

Переход на сервер с использованием функции Date () также должен работать (возвращая универсальное значение даты).

Кроме того, используйте объект команды и параметры в запросе, когда вы передаете их, чтобы избежать атак внедрения SQL на строковые поля.

Answer 3

Почему бы не использовать формат

dd mmm yyyy

Существует только один способ интерпретации.

Answer 4

Извините, я не знаю mysql, но с оракулом я бы всегда указывал explicity, в каком формате я ожидал, например, в формате «DD-MM-YYYY», чтобы избежать (региональных) проблем с форматом даты

Answer 5

Access использует # в качестве разделителя поля даты. Формат должен быть # мм / дд / гггг # вероятно # мм-дд-гггг # также будет работать нормально.

Answer 6

Я бы предположил, что функция fCSQLDate специфична для культуры - то есть она будет анализировать дату на основе настроек локали пользователя. Вот почему вы видите проблему.

В любом случае, использование запросов со связанными строками всегда плохая идея (атаки с использованием инъекций). Вам лучше, если вы используете параметры.