C# nom d'objet non Valide ASP.NET

Je suis en train de récupérer des documents à mon gridview dgvEmployees de ma table tblEmployees. Je ne suis pas sûr de ce qui est mal, peut-être à cause de la syntaxe? Mais le code a travaillé auparavant à l'aide de MS Visual C# 2010 Express (WinForms seulement). Je suis actuellement à la création d'une page web avec les winforms à l'aide de MS Visual Studio (ASP.NET - C#). Voici mon code:

    SqlConnection sConn;
    SqlDataAdapter daEmp;
    DataSet dsEmp;

    const string sStr = "Server = MYSERVER\\SQLEXPRESS; 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"];

    }

Voici le message d'erreur sur cette ligne (daEmp.Fill(dsEmp, "tblEmployees");

Invalid object name 'tblEmployees'

S'il vous plaît aider. Merci!

  • L'utilisateur qui exécute le code (donc, par exemple, l'identité est définie pour le pool d'applications du site web) ont accès à la base de données?
  • Il n'est pas possible de répondre sans voir le schéma de base de données. Cependant, ce sont les possibilités à explorer: 1) Est tblEmployees stockées dans un schéma autre que "dbo"? 2) Si vous copiez le code SQL dans SQL Management express (ou toute requête en cours d'exécution) avez-vous un problème? 3) Êtes-vous sûr que vous vous connectez à la base de données correcte? 4) - la table de base de données pas la marque du pluriel?
  • Base de données correcte, oui. Et quand j'essaie de INSERT INTO, il dit la même erreur. Mais je peux ajouter manuellement des enregistrements quand j'ai ouvert la table...
InformationsquelleAutor user2971155 | 2013-11-13
  1. 2

    L'erreur est en se référant à la requête SQL ne pas le DataSet. En d'autres termes, le problème n'est pas avec le C#. Vous devez vérifier votre chaîne de connexion et assurez-vous que la table existe dans la base de données.

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

    Cette requête est mauvaise: Select * from tblEmployees

    Vous pouvez vérifier cela en modifiant la requête: Select * from IDONTEXIST

    Vous verrez une erreur similaire:

    nom d'objet non valide IDONTEXIST

    InformationsquelleAutor P.Brian.Mackey
  2. 2

    Vous êtes maintenant en cours d'exécution de l'application sur le site web de sorte que l'utilisateur qui se connecte à SQL server est celui qui est en cours d'exécution de votre pool d'applications IIS lorsque vous utilisez Integrated Security = SSPI dans votre chaîne de connexion.

    Vous devez soit:

    1. Donner accès à la base de données pour le pool d'applications de l'utilisateur (pas une bonne idée pour celui par défaut).
    2. Changer l'utilisateur pour le pool de connexion pour un utilisateur qui a accès à la base de données.
    3. Spécifier un utilisateur qui a accès dans la chaîne de connexion.
    • Merci, mon problème est que je n'ai pas fournir Initial Catalog dans la chaîne de connexion pour le ski de requêtes de base de données.
    InformationsquelleAutor Szymon
  3. 1

    Vous devez tout d'abord vérifier votre chaîne de connexion:

    • De s'assurer qu'il est de se connecter à l'instance de SQL Server que vous pensez.
    • De s'assurer qu'il est en train d'établir le contexte de base de données pour la connexion à la base de données vous pensez qu'il est.
    • De s'assurer qu'il est de se connecter avec les identifiants que vous pensez qu'il est.
    • De s'assurer que ces informations d'identification de la carte à l'utilisateur de SQL Server que vous pensez qu'il devrait
    • Que SQL Server de l'utilisateur a le schéma par défaut vous pensez que cela fonctionne et qu'il possède les droits accordés dans la base de données.

    Presque certainement, votre problème découle de l'un ou plusieurs des thèmes cités ci-dessus.

    Si votre contexte de base de données pour la connexion se trouve dans une autre base de données que vous le pensez, vous n'aurez probablement pas trouver les objets que vous recherchez.

    Si votre objet les références ne sont pas de schéma-qualifiés, vous pouvez avoir un problème de résolution des références d'objet. Les références de l'objet dans vos requêtes SQL doit toujours, à tout le moins, être de schéma-qualifiés. Au lieu de dire

    select * from tblEmployees

    vous dire

    select * from dbo.tblEmployees

    où dbo est le schéma qui est propriétaire de l'objet. Toutes les références à des objets qui ne sont pas de schéma-qualifiés sont considérés au moment de l'exécution dans l'ordre suivant

    1. Tout d'abord, l'utilisateur actuel du schéma par défaut est détecté pour un objet du nom de votre choix.
    2. Si cela échoue, la dbo schéma ('base de données propriétaire"), est sondé pour un objet du nom de votre choix.

    Pour les procédures stockées, la recherche est plus complexe:

    1. De la sonde de l'utilisateur actuel du schéma par défaut dans la base de données actuelle.
    2. De la sonde de la " dbo " schéma dans la base de données actuelle.

    Si le nom de la procédure stockée commence avec "sp_',

    1. De la sonde de l'utilisateur actuel du schéma par défaut dans la base de données principale.
    2. De la sonde de la " dbo " schéma dans la base de données principale.

    Si l'objet en question appartient à un autre schéma, il ne sera pas trouvé, à moins qualifiés par le propriétaire du schéma.

    En raison de la recherche de multiples problème, l'absence de schéma de qualification peuvent empêcher l'exécution du plan de mise en cache, ce qui signifie que le plan de requête doit être recompilé à chaque exécution d'une requête. Inutile de dire que cela a...sous-optimale les effets sur la performance.

    En outre, vous pouvez obtenir...intéressant...les résultats si votre base de données utilisateur est " dev "et le dev en question, 6 mois en arrière, créé un tableau ou d'un autre objet nommé" dev.foo' au cours du développement. Maintenant, vous êtes en direct dans la production et la connexion en tant qu'utilisateur "dev". L'exécution de select * from foo vont se lier à dev.foo, de préférence à la production réelle de la table que l'administrateur de la base créée, 'dbo.foo'. Vos utilisateurs se demandent pourquoi leurs données sont manquantes ou vous serez ripper vos cheveux en se demandant pourquoi l'application est pleurnicher sur des colonnes manquantes quand ils semblent être là quand vous le regardez via le SQL server Management Studio.

    InformationsquelleAutor Nicholas Carey