aidez-moi s'il vous plaît, je ne sais pas ce qui peut se tromper avec le code suivant: Ce code me jette merci. P> P> trop peu de paramètres. Code> Erreur quand je J'essaie d'exécuter la requête. La base de données va bien, cela fonctionne bien lorsque j'entraîne des valeurs du codes racontées dans une requête, au lieu d'utiliser des paramètres. P>
4 Réponses :
Une de vos colonnes dans votre requête n'existe pas.
Veuillez vérifier vos noms de colonne. p>
Vous verrez généralement cela lorsque vous manquez un nom de colonne dans votre relevé SQL. Êtes-vous sûr de ces noms de colonne (détenu, custername, etc.)? P>
Je suis assez sûr, car si je change de troisième ligne de ma requête sur des valeurs réelles, cela fonctionne bien.
Essayez de changer de passe en passw peut-être que cela se mêle à l'identifiant ASP ... P>
de MSDN:
Lorsque COMMANDTYPE est défini sur SMS, le fournisseur de données .NET Framework pour ODBC ne prend pas en charge la passation des paramètres nommés à une instruction SQL ou à une procédure stockée appelée ODBCCommand. Dans l'un de ces cas, utilisez l'espace réservé à la marque (?). Par exemple: p> blockquote>
xxx pré> réécrire votre requête à p>
xxx pré> ordre des numéros de paramètre! p>
EDIT: modifier: paramètre peut être ajouté de cette façon: p>
xxx pré> p>
Utilisation de ODBC à Filmaker, cette syntaxe a parfaitement fonctionné dans l'environnement .NET et oui l'ordre des paramètres compte!
Si les paramètres de requête ne sont pas nommés, quel but le premier paramètre dans paramètre.add () code> servit?
@Scott: Autres fournisseurs de données utilisez le paramètre nommé. Donc je suppose que la raison est d'avoir la même API
Vous pouvez toujours vouloir utiliser les noms afin que vous puissiez rechercher le paramètre pour définir le paramètre pour les appels ultérieurs. Je ne l'ai pas encore essayé à OdbcCommand, mais ils sont utiles pour d'autres fournisseurs de base de données.
Essayez de changer de passe en passw peut-être qu'il se mêle à l'identifiant ASP ...