C# недопустимое имя объекта ASP.NET

Я пытаюсь получить записи в мой GridView данных dgvEmployees из-за моего стола tblEmployees. Я не уверен, что не так, хотя, может быть, из-за синтаксиса? Но код работал до использования MS Visual C# 2010 Express (только WinForms). В настоящее время я создаю веб-страницу с winforms с помощью MS Visual Studio (ASP.NET -c#). Вот мой код:

    SqlConnection sConn;
    SqlDataAdapter daEmp;
    DataSet dsEmp;

    const string sStr = "Server = MYSERVERSQLEXPRESS; Database = EMPLOYEES; Integrated Security = SSPI";

    protected void Page_Load(object sender, EventArgs e)
    {
        sConn = new SqlConnection(sStr);
        daEmp = new SqlDataAdapter("Select * from tblEmployees", sConn);
        dsEmp = new DataSet();

        daEmp.Fill(dsEmp, "tblEmployees");

        dsEmp.Tables["tblEmployees"].PrimaryKey = new DataColumn[] { dsEmp.Tables["tblEmployees"].Columns["EmployeeID"] };

        dgvEmployees.DataSource = dsEmp.Tables["tblEmployees"];

    }

вот сообщение об ошибке в этой строке (daEmp.Fill(dsEmp, "tblEmployees");

Invalid object name 'tblEmployees'

пожалуйста, помогите. Спасибо!

6
c# sql sql-server tsql

3 ответов

ошибка ссылается на SQL-запрос, а не на DataSet. Другими словами, проблема не в C#. Вам нужно проверить строку подключения и убедиться, что таблица существует в БД.

daEmp = new SqlDataAdapter("Select * from tblEmployees", sConn);

запрос-это плохо: Select * from tblEmployees

вы можете проверить это, изменив запрос на:Select * from IDONTEXIST

вы увидите аналогичную ошибку:

недопустимое имя объекта IDONTEXIST

2

теперь вы запускаете приложение на веб-сайте, поэтому пользователь, который будет подключаться к SQL server, запускает пул приложений в IIS при использовании Integrated Security = SSPI в строке подключения.

вам понадобится:

  1. предоставить доступ к базе данных для пользователя пула приложений (не очень хорошая идея для пользователя по умолчанию).
  2. измените пользователя пула соединений на пользователя, имеющего доступ к базе данных.
  3. указать пользователя у кого есть доступ в строке подключения.
2

сначала проверьте строку подключения:

  • убедитесь,что он подключается к экземпляру SQL Server, который вы считаете.
  • убедитесь,что он устанавливает контекст базы данных для соединения в базе данных, которую вы считаете.
  • убедитесь, что он соединяется с учетными данными, которые вы думаете, что это так.
  • убедитесь, что эти учетные данные сопоставляются с пользователем SQL Server, который, по вашему мнению, должен
  • что это SQL Пользователь сервера имеет схему по умолчанию, как вы думаете, и имеет соответствующие права, предоставленные в базе данных.

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

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

если ваши ссылки на объекты не соответствуют схеме, у вас может возникнуть проблема с решением объекта ссылки на литературу. Ссылки на объекты в ваших SQL-запросах всегда должны быть, по крайней мере, квалифицированы схемой. Вместо того чтобы сказать

select * from tblEmployees

вы должны сказать

select * from dbo.tblEmployees

здесь dbo - это схема, которой принадлежит объект. Любые ссылки на объекты, которые не соответствуют схеме, просматриваются во время выполнения в следующем порядке

  1. во-первых, схема текущего пользователя по умолчанию зондируется для объекта с требуемым именем.
  2. если это не удается, dbo схема ("владелец базы данных") исследуется для объекта с требуемым именем.

для хранимых процедур поиск более сложный:

  1. щуп схемы текущего пользователя по умолчанию в текущей базе данных.
  2. Проверьте схему " dbo " в текущей базе данных.

если имя хранимой процедуры начинается с sp_',

  1. Проверьте схему текущего пользователя по умолчанию в "master" база данных.
  2. Проверьте схему " dbo "в базе данных "master".

если объект, о котором идет речь, принадлежит другой схеме, он не будет найден, если не квалифицирован схемой владельца.

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

Далее, вы можете получить...интересный...результаты, если ваш пользователь базы данных является "dev", а dev, о котором идет речь, 6 месяцев назад, создал таблицу или другой объект с именем " dev.Фу Во время развития. Теперь вы живете в производстве и подключаетесь как пользователь "dev". Выполнение select * from foo свяжет с dev.foo в предпочтении к фактической производственной таблице, которую создал DBA, ' dbo.фу. Ваши пользователи будут задаваться вопросом, почему их данные отсутствуют, или вы будете рвать волосы, задаваясь вопросом, почему приложение скулит о недостающих столбцах, когда они появляются все там, когда вы смотрите на него через SQL Management Studio.

1