2009-04-02 4 views
7

J'essaie d'insérer un enregistrement dans une table dans une configuration de base de données à trois niveaux et le serveur intermédiaire génère le message d'erreur ci-dessus en tant qu'exception OLE lorsqu'il tente d'ajouter le premier paramètre à la requête. J'ai cherché cette erreur, et je trouve le même résultat de manière cohérente: il vient d'avoir un deux-points dans une chaîne quelque part dans votre requête, ce qui bloque l'analyseur SQL d'ADO. Ce n'est pas le cas ici. Il n'y a pas de deux-points faux partout. J'ai vérifié et revérifié la définition de l'objet par rapport au schéma de la table dans laquelle j'essaie d'insérer. Tout vérifie, et cela a perplexe mes collègues. Est-ce que quelqu'un sait quoi d'autre pourrait causer cela? Je suis à bout de nerfs ici.Delphi: "L'objet de paramètre est mal défini, des informations incohérentes ou incomplètes ont été fournies."

J'utilise Delphi 2007 et SQL Server 2005.

+0

@Mason - Utilisez-vous des paramètres? Si non, est-ce que le réglage de ParamCheck: = Faux aide? –

+0

J'utilise des paramètres. –

Répondre

0

Si je me souviens bien, vous devez explicitement la valeur NULL mis au paramètre. Si vous utilisez un composant TAdoStoredProc, vous devez le faire au moment du design.

0

Utilisez-vous un filetage? Je me souviens d'avoir eu cette erreur lorsqu'un événement timer a démarré une requête pendant que la connexion ADO était utilisée pour une autre requête synchrone. (La minuterie vérifiait un "système disponible" drapeau chaque minute).

0

Avez-vous défini le DataType du paramètre ou l'avez-vous laissé comme ftUnknown?

+0

Le type de données a été défini. –

4

Je peux obtenir cette erreur, en utilisant Delphi 2007 et MSSQL Server 2008, et j'ai trouvé une solution de contournement. (. Ce qui est assez merdique à mon humble avis, mais peut-être son utile pour vous si le vôtre est causé par la même chose)

Code

pour produire l'erreur:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode').Value := 1; 

    Open; // <<<<< I get the "parameter object is...etc. error here. 

finally 
    Free; 
end; 

j'ai trouvé deux façons de le fixer:

1) supprimer les crochets du SQL, à savoir:

SQL.Text := ' SELECT * FROM Stock WHERE InvCode = :InvCode ' 
       +' SELECT * FROM Stock WHERE InvCode = :InvCode '; 

2) en utilisant deux paramètres au lieu d'un:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode1) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode2) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode1').Value := 1; 
    Parameters.ParamByName('InvCode2').Value := 1; 

    Open; // <<<<< no error now. 

finally 
    Free; 
end; 
2

Voici une réponse tardive. Dans mon cas, c'était quelque chose de complètement différent.

J'ai essayé d'ajouter une procédure stockée à la base de données.

Query.SQL.Text := 
'create procedure [dbo].[test]' + #13#10 + 
'@param int ' + #13#10 + 
'as' + #13#10 + 
'-- For the parameter you can pick two values:' + #13#10 + 
'-- 1: Value one' + #13#10 + 
'-- 2: Value two'; 

Lorsque j'ai supprimé le deux-points (:) cela a fonctionné. Comme il a vu le colon en tant que paramètre.

1

Je suis confronté à la même erreur décrite dans votre question. En utilisant des points d'arrêt, l'erreur a été soulevée dans mon cas par un paramètre qui devrait remplir un champ DateTime dans la base de données et je n'ai jamais rempli le paramètre. configurer le paramètre(). value: = '' résolu le problème (j'ai essayé aussi avec varnull, mais il y a un problème - au lieu d'envoyer Null dans la base de données, query envoie 1 - la valeur entière de varnull). PS: Je sais que c'est une réponse tardive tardive, mais peut-être que quelqu'un atteindra la même erreur.

+0

Avait un problème comme ça, mais l'a obtenu en envoyant NULL (voir ma réponse) – BennyBechDk

+0

J'ai le même problème en ce moment, ce qui arrive parfois, parfois non, et j'ai également réussi à le tracer à TParameters.AppendParameters. J'ai remarqué que le paramètre qui causait le problème était assigné la valeur NULL. Le changer en Non attribué semble avoir résolu le problème. Mais ce qui me dérange vraiment, c'est le fait que l'erreur ne se produirait que parfois. –

0

J'ai également eu le même problème, mais avec une commande dynamique (par exemple une instruction Update).
Certains des paramètres pourraient être NULL.
La seule façon de le faire fonctionner, était de définir le paramètre.DataType: = ftString et parameter.Size: = 1 et ne définissant pas la valeur.

cmdUpdate := TADOCommand.Create(Self); 
try 
    cmdUpdate.Connection := '**Conections String**'; 
    cmdUpdate.CommandText := 'UPDATE xx SET yy = :Param1 WHERE zz = :Param2'; 
    cmdUpdate.Parameters.ParamByName('Param2').Value := WhereClause; 
    if VarIsNull(SetValue) then 
    begin 
    cmdUpdate.Parameters.ParamByName('Param1').DataType := ftString; 
    cmdUpdate.Parameters.ParamByName('Param1').Size := 1; 
    end else cmdUpdate.Parameters.ParamByName('Param1').Value := SetValue; 
    cmdUpdate.Execute; 
finally 
    cmdUpdate.Free; 
end; 
3

J'ai trouvé ce fil lors de la recherche du message d'exception mentionné précédemment. Dans mon cas, la cause était une tentative d'intégration d'un commentaire SQL/* foo */dans mon query.sql.text.

(je pensais qu'il aurait été utile de voir un commentaire aller flottant passé dans ma fenêtre de profileur.)

Quoiqu'il en soit - Delphi7 haï celui-là.

+0

La même chose pour moi, dans Delphi 2010. J'ajoutais un commentaire "- foo", cependant. –

0

Je viens de rencontrer cette erreur aujourd'hui sur un TADOQuery qui a ParamCheck := False et n'a pas de deux-points dans le SQL.

passant une certaine façon le paramètre OLECMDEXECOPT_DODEFAULT à TWebBrowser.ExecWB() était à l'origine pour moi:

Cela montre le problème:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DODEFAULT, pvaIn, pvaOut); 

Cela ne montre pas le problème:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DONTPROMPTUSER, pvaIn, pvaOut); 
0

Une simple double citation dans la requête peut également élever cette erreur de ce que je viens de vivre et je ne suis pas chanter paramètres du tout ...

1

Je viens de rencontrer cette erreur moi-même. J'utilise Delphi 7 pour écrire dans une base de données MS Access 2003 en utilisant un composant TAdoQuery. (ancien code) Ma requête a fonctionné correctement directement dans MS Access, mais échoue dans Delphi à travers l'objet TAdoQuery. Mon erreur est venue d'un colon (excuses à l'affiche originale) d'une valeur date/heure. Si je comprends bien, le format date/heure de Jet SQL est # mm/jj/aaaa hh: nn: ss # (0 remplissage à gauche n'est pas requis).

Si la propriété TAdoQuery.ParamCheck a la valeur True, ce format échoue. (Merci les affiches!) Deux solutions sont: a) mettre ParamCheck à False, ou b) utiliser un format de date/heure différent, à savoir "mm/jj/aaaa hh: nn: ss" (avec les guillemets doubles).

J'ai testé ces deux options et toutes deux ont fonctionné.

Même si ce format de date/heure à double guillemet n'est pas le format date/heure Jet, Access est assez flexible pour être flexible sur ces formats date/heure. Je soupçonne également qu'il a quelque chose à voir avec le format de date/heure de BDE/LocalSQL/Paradox (SQL natif de Delphi 7 et moteur de base de données) (utilise des guillemets, comme ci-dessus). L'analyseur est probablement conçu pour ignorer les chaînes entre guillemets (les guillemets doubles sont le délimiteur de valeur de chaîne dans BDE LocalSQL), mais peut trébucher quelque peu sur d'autres formats date/heure non natifs.

SQL Server utilise des guillemets simples pour délimiter les chaînes, ce qui peut fonctionner au lieu de guillemets lors de l'écriture dans des tables SQL Server (non testées). Ou peut-être que l'objet Delphi TAdoQuery trébuchera encore. Désactiver ParamCheck dans ce cas peut être la seule option. Si vous envisagez de basculer la valeur de la propriété ParamCheck dans le code, vous économiserez du temps de traitement en vous assurant que la propriété SQL est vide avant de l'activer, si vous n'avez pas l'intention d'analyser le SQL actuel.

0

Vous pouvez obtenir cette erreur lorsque vous essayez d'utiliser une valeur de temps dans le SQL et oubliez de l'envelopper avec QuotedStr().

0

J'ai eu la même erreur. Il s'est avéré que c'est parce qu'un paramètre de la procédure stockée a été déclaré comme varchar (max). Fait varchar (4000) et l'erreur a disparu.

Questions connexes