Je suis coincé dans un problème assez étrange avec SQL Server 2005, qui jette
"Définisseur indiqué doit être activé lors de l'insertion d'enregistrement"
(en utilisant comme SP) sur la table concernée. Cela a fonctionné bien plus tôt mais je lance cette erreur au hasard.
J'ai vérifié le sp. Nous n'avons pas spécifié manuellement défini sur les paramètres d'identifiant indiqués à l'intérieur. Il doit donc être activé par défaut.
Quelqu'un peut-il clarifier ce qui pourrait être le problème?
La table doit être créée avec l'identifiant indiqué à droite? Je n'ai pas encore vérifié le script de table.
J'ai constaté que ce problème ne se produit que avec les SPS qui effectue une insertion ou une mise à jour sur une colonne de date (modifiée) ... une valeur d'échantillon est '2009-08-10 06: 43: 59: 447' ..
Y a-t-il un problème avec les valeurs passées?
4 Réponses :
dans SQL Server 2005, définissez l'identifiant cité est désactivé par défaut, non sur (sauf en utilisant une connexion ODBC ou OLE ... voir Vous n'avez pas besoin de créer la table avec définir l'identifiant indiqué pour l'utiliser.
Tout ce que vous avez à faire est d'ajouter un identifiant indiqué sur le début de votre SP pour l'activer pour la course de la procédure (et assurez-vous que si vous ne souhaitez pas le laisser, vous avez défini l'identifiant cité. Off pour le retourner).
Je suis corrigé. Selon ce Page MSDN , définissez l'identifiant indiqué est sur défaut (sauf si la connexion avec une application de la Bibliothèque de DB.
Je faisais référence à cette page ... MSDN.MicRosoft.com /en-us/library/ms174393(SQL.90).aspx .. Ça dit sur Dafault ..
En fait, nous inscrits à appliquer un identifiant indiqué sur l'une de vos SPS. tous les SPS de la DB Creatd de cette façon. Seul l'insertion particulière SP sur la table particulière jette cette erreur ... Nous pourrions facilement résoudre ce problème si cela se produit toujours ... c'est déployé il y a une semaine, ça marche bien jusqu'à Aujourd'hui .. et soudainement donner à ce problème .. aucune idée pourquoi cela se comporte comme ça ...
Assurez-vous de construire de manière dynamique des requêtes SQL dans la procédure stockée. Cela pourrait conduire à certaines données que l'utilisateur entrait avec des guillemets doubles à introduire dans la requête. Lorsque SQL Server tente d'exécuter la requête ... vous obtenez cette erreur.
Je lisais simplement cet article par Erland Sommmarskog, La malédiction et les bénédictions de SQL dynamique , et il inclut le paragraphe suivant en ce qui concerne la définition de l'identifiant indiqué:
la valeur par défaut pour cela
le réglage dépend du contexte, mais le
Le réglage préféré est allumé, et il doit
être sur afin d'utiliser XQuery, indexé
Vues et index sur colonnes calculées.
Votre procédure stockée utilise-t-elle des vues XQuery, des vues indexées ou des index sur des colonnes calculées du tout?
Merci pour le courrier électronique de réponse, nous n'utilisons aucune fantaisie XQuery ou d'autres fonctionnalités. C'est juste une insertion simple et une mise à jour SP .. et il n'a pas trop de vues indexées ...
Script Script Le ProC stocké, Assurez-vous / modifier les options de jeu, exécutez l'Alter ProC pour vous assurer que Définir l'identificateur indiqué est défini.
Le réglage de "Définir l'identifiant cité" est défini au délai de création pour les Procs stockés et est toujours "ON" pour les tables. Source, Bol .
Quand une table est créée, le cité
L'option d'identifiant est toujours stockée comme
Sur les métadonnées de la table même si la
L'option est définie sur OFF lorsque la table est
créé.
Lorsqu'une procédure stockée est créée,
l'ensemble cité_dentifiant et défini
Les paramètres ANSI_NULLLS sont capturés et
utilisé pour les invocations ultérieures de
cette procédure stockée.
La valeur par défaut pour les connexions peut être définie au niveau du serveur (options utilisateur SP_Configure ') ou niveau de la base de données (Alter base de données). Pour SSMS, il est sous "Outils..OPTIONS .. Exécution de la requête..SQL Server..ansi". C'est aussi la valeur par défaut des bibliothèques clientes (sauf db-lib).
Maintenant, vous ouvrez une fenêtre de requête SSMS et commencez à taper "Créer proc ..", alors il utilise des paramètres SSMS lorsque vous exécutez le code.
et définir l'identifiant cité ne peut pas être défini au moment de l'exécution à l'intérieur du procès stocké. Montrez-moi la référence A avant d'être en désaccord ... à partir du lien MS Bol ci-dessus:
lorsqu'il est exécuté à l'intérieur d'un stockage
Procédure, le réglage de l'ensemble
Cité_dentifiant n'est pas modifié.
Vous devez travailler dur pour exécuter n'importe quel code avec ceci ... Donc, la solution la plus probable est de modifier ou de recréer la procuration stockée.
Après une longue lutte, nous avons pu résoudre ce problème. Je voulais juste partager la raison.
Notre équipe de construction maintient un outil interne séparé pour déployer des scripts, ce qui déclenche en interne l'utilitaire Voici le coupable: Par défaut, Chaque script exécuté via cet outil est créé avec Remarque: je vais voter le message de tous comme utile. cité_dentifier est éteint lors de l'exécution en mode SQLCMD!
identifiant cité off . Nous sommes le seul module qui utilise des vues indexées. Toutes les histoires restantes que vous connaissez bien dans mes postes précédents: (
Vous venez de m'avoir sauvé au moins une heure de chasse --- Je n'aurais pas deviné que SQLCMD l'envisageait. Merci d'avoir ajouté cette clarification
Génial ... j'ai lutté avec ce problème pendant près d'une semaine. C'est une fauve d'erreur simple. Je pensais que cela pourrait être utile pour quelqu'un .. je suis très heureux que cela vous ait aidé ... :)
Ditto sur les commentaires de @alph Shillington.
Courut exactement ce problème et cela me conduisait fou - merci de me faire remarquer dans la bonne direction. Passage FWIW -I à SQLCMD changera cette option. Même donc, je pense que je vais passer à l'utilisation de crochets dans mes identifiants à la place!