Datareader не возвращает результатов в VS, но хранимая процедура возвращает несколько наборов результатов на сервере Sql

Когда вы получаете сообщение об ошибке «IEnumerable не вернул результатов»? Не могли бы вы показать пример доступа к DataReader?

Что произойдет, если вы установите точку останова перед возвратом и запустите

rdrFilterSearch.GetString(0);

в ближайшем окне?

Вы когда-нибудь добавляли параметры в коллекцию параметров SqlCommand? Вы упомянули, что не работают те, которые принимают входные параметры, но в вашем коде нет ничего подобного:

cmdPopulateFilterDropDowns.Parameters.AddWithValue(...);

Запустите трассировку SQL-сервера для сервера, на котором, как вы думаете, вы выполняете свою команду. Что на самом деле отправляется на сервер? Думаю, там ты найдешь ключ к разгадке дымящегося пистолета.

У BFree есть хороший аргумент, чтобы проверить AddWtihValue () против Add (). Также убедитесь, что если вы явно создаете экземпляры объектов SqlParameter, может возникнуть та же проблема, что и у вас с .Add (). Обратите внимание, что есть недостаток дизайна с Parameters.Add (), когда вы передаете в него значения (int) 0 - они принимаются как перечисление вместо значения ...

это может показаться очевидным, но скажите, пожалуйста, что вы вызываете метод .Read ()? Ненавижу задавать такой вопрос, но иногда это самые очевидные вещи, которые мы забываем, когда сводим себя с ума из-за проблемы.

Глупая ошибка с моей стороны. После нескольких часов работы с этим я понял, что хранимые процедуры, которые я использовал, возвращают несколько наборов результатов, из которых первый набор результатов всегда был пуст. Отсюда отсутствие результатов.

Установка параметра в sqlParam должна решить проблему.

mySqlParam.Direction = ParameterDirection.ReturnValue;

Если вы ожидаете, что будет возвращено более одного значения, просто добавьте параметр и установите его направление:

    SqlParameter mySqlParam = new SqlParameter();
    mySqlParam.ParameterName = "@ID";
    mySqlParam.SqlDbType = SqlDbType.int;
    mySqlParam.Direction = ParameterDirection.ReturnValue;

    SqlParameter mySqlParam = new SqlParameter();
    mySqlParam.ParameterName = "@Name";
    mySqlParam.SqlDbType = SqlDbType.NVarChar;
    mySqlParam.Direction = ParameterDirection.ReturnValue;


    SqlParameter mySqlParam = new SqlParameter();
    mySqlParam.ParameterName = "@Address";
    mySqlParam.SqlDbType = SqlDbType.NVarChar;
    mySqlParam.Direction = ParameterDirection.ReturnValue;

mySqlParam.ParameterName не обязательно должен точно соответствовать имени в хранимой процедуре.

Затем вы можете прочитать такие значения (пример не полный):

int.Parse(dataReader["ID"]);
dataReader["name"].ToString();
dataReader["address"].ToString();

значение в dataReader[""].ToString(); должно соответствовать имени столбца из хранимой процедуры.

У меня была похожая, но не идентичная проблема, которая сводила меня с ума, поэтому я брошу ее на случай, если она кому-то поможет.

Я мог бы запустить SQL или вызвать хранимую процедуру с тем же SQL на SQL Server с помощью Management Studio и получить обратно заполненный набор результатов. Но когда я использовал идентичный встроенный SQL или вызвал содержащий его sproc из моего кода Visual Studio для проекта веб-приложения ASP.Net, я получил пустой DataReader.

Как тот же идентичный SQL может вернуть набор результатов в Management Studio, но пустой DataReader в Visual Studio? Ответ заключался в том, что я работал как другой пользователь с разными разрешениями в двух инструментах. В Management Studio я работал разработчиком с определенной ролью SQL с множеством разрешений. Но в Visual Studio я работал как учетная запись службы, которой не были предоставлены разрешения на запрашиваемые мной таблицы.

На самом деле моя проблема была на шаг сложнее. Все было хорошо, пока я не изменил SQL / sproc и не добавил таблицу JOIN к еще одной таблице, и в этой таблице не было необходимых разрешений для учетной записи службы. Но принцип тот же: проверьте все разрешения для пользователя, выполняющего вызов базы данных.

Использовать

reader.ExecuteNonQuery() 

Удачного кодирования