Блог

Главная - Вопросы по программированию - C # и MS Access SQL с разделителем даты

C # и MS Access SQL с разделителем даты

#c# #sql #ms-access

#c# #sql #ms-access

Вопрос:

Я столкнулся с ошибкой с этим запросом

 "SELECT COUNT(*) AS x FROM accounts_info ";
        query  = "INNER JOIN customers_info ON accounts_info.cust_code = customers_info.cust_code ";
        query  = "WHERE accounts_info.date_due >= #@a# AND accounts_info.is_paid = 0";

OleDbCommand cmd = new OleDbCommand(query, con);
String aaa = DateTime.Now.ToString("MM/dd/yyyy");
cmd.Parameters.AddWithValue("@a", aaa);

о чем мне сообщает ошибка: Дополнительная информация: Синтаксическая ошибка в дате в выражении запроса ‘accounts_info.date_due > = #@a # И accounts_info.is_paid = 0’.

Могу ли я вставить параметр в разделитель даты #1/13/2021 #, например #@param @ #?

Комментарии:

1. Я не думаю, что вам нужно # обойти @a , и вы должны просто передать DateTime.Now.Date вместо aaa .

2. — или в краткой форме: DateTime.Today .

Ответ №1:

Две вещи

  • Удалите #
  • Сделайте значение параметра датой, а не строкой

Нравится…

 "SELECT COUNT(*) AS x FROM accounts_info ";
    query  = "INNER JOIN customers_info ON accounts_info.cust_code = customers_info.cust_code ";
    query  = "WHERE accounts_info.date_due >= @a AND accounts_info.is_paid = 0";

OleDbCommand cmd = new OleDbCommand(query, con);
cmd.Parameters.AddWithValue("@a", DateTime.Now.Date); //.Date will remove time portion from date

Примечание..

OLEDB не выполняет именованные параметры. Вы можете поместить их в имена, но имя, которое вы даете, не имеет значения, важен порядок .. коллекция параметров должна содержать такое же количество параметров и в том же порядке, в каком они отображаются в SQL. По этой причине, а также для того, чтобы не думать, что имя параметра можно повторно использовать несколько раз в запросе, некоторые люди используют ? метки для заполнителей параметров

 "SELECT COUNT(*) AS x FROM accounts_info ";
    query  = "INNER JOIN customers_info ON accounts_info.cust_code = customers_info.cust_code ";
    query  = "WHERE accounts_info.date_due >= ? AND accounts_info.is_paid = 0";

OleDbCommand cmd = new OleDbCommand(query, con);
cmd.Parameters.AddWithValue("p1", DateTime.Now.Date);

Комментарии:

1. Что делать, если пользователь хочет изменить запрос? Даже небольшое изменение? Затем снова изменение кода. Снова развертывание приложения. Слишком много головной боли для небольшого изменения. Давайте предположим, что запрос большой? Тогда слишком много строковых операций? Снова проблема с производительностью

2. О чем ты говоришь? Если пользователь хочет изменить запрос, а запрос представляет собой код, то это изменение кода.. Не имеет значения, где он хранится . Если вы хотите, чтобы изменения вступили в силу, их необходимо развернуть . Открытие базы данных в access, изменение кода и нажатие кнопки сохранить — это изменение кода и выполнение развертывания . Вы утверждаете, что существует огромная разница между «открыть Visual studio, изменить код, нажать опубликовать» и «открыть доступ, изменить код, нажать Сохранить» — абсолютная бессмыслица

3. вы также делаете то же самое, босс. Просто подумайте об этом, нужно ли повторно развертывать все приложение, если это можно сделать, просто изменив один SP

4. вы можете протестировать SO отдельно, вы также можете проверить синтаксическую ошибку. Во время работы с кодом вам необходимо выполнить весь поток для тестирования и отладки SP

5. Итак, вы хотите сказать, что вам нравится играть быстро и свободно с такими вещами, как управление изменениями, сквозное тестирование, и вам нравится разбрасывать свой код повсюду .. ОК. Я понимаю ваши замечания, но я никогда не соглашусь с тем, что они обязательны для решения этой проблемы в представленном виде. У меня больше нет вклада в это обсуждение

Ответ №2:

Ваш запрос выдает ваш запрос ниже.

 SELECT COUNT(*) AS x FROM accounts_info
INNER JOIN customers_info ON accounts_info.cust_code = customers_info.cust_code
WHERE accounts_info.date_due >= #@a# AND accounts_info.is_paid = 0

поэтому, пожалуйста, удалите # из запроса.

Также, пожалуйста, создайте хранимую процедуру и передайте параметр вместо записи запроса в коде.

Комментарии:

1. Действительно? Хранимая процедура? Почему, когда запрос может быть / уже параметризован, конец?

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

3. Сохранение логики доступа к apsara вашего приложения в другом месте, отличном от остальной части кода приложения, — это не то, что я называю «слабой связью», это просто альтернативная стратегия управления кодом или, возможно, головная боль при управлении изменениями, но у каждого своя. Моя главная проблема с вашей рекомендацией сделать это заключается в том, что она читается так, как будто это необходимо для решения проблемы, когда это не так

4. @CaiusJard это просто предложение для хорошей практики

5. Я указываю, что это не читается как предложение, оно читается как инструкция. Добавьте несколько слов вроде «в качестве альтернативы вы могли бы создать хранимую процедуру ..», если это ваше намерение.. Я не считаю это особенно «хорошей практикой», чем, например, сохранение текста запроса в текстовом файле, который развертывается вместе с приложением. Все, что вы делаете с хранимой процедурой, — это меняете место хранения текста запроса; изменения все равно должны быть «скомпилированы» и «развернуты». Взятие параметризованного запроса и создание параметризованной хранимой процедуры, которую вы должны вызвать с параметризованным запросом, здесь бессмысленно