Delphes: “Paramètre de l'objet n'est pas définie correctement. Les informations incomplètes ou incohérentes ont été fournis.”

Je peux obtenir cette erreur, à l'aide de Delphi 2007 et MSSQL Server 2008, et j'ai trouvé une solution de contournement. (ce qui est assez merdique à mon humble avis, mais c'est peut-être utile pour vous, si le vôtre est causée 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 solutions pour y remédier:

1) supprimer les crochets du SQL, c'est à dire:

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

2) l'utilisation de 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;

OriginalL'auteur

Ici 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 dans 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';

Quand j'ai enlevé les deux-points (:), il a travaillé. Comme il a vu le côlon comme un paramètre.

OriginalL'auteur

Je viens de rencontré cette erreur moi-même. Je suis l'aide de Delphi 7 pour écrire à 2003, MS Accès base de données à l'aide d'un TAdoQuery composant. (ancien code) Ma requête a bien fonctionné directement dans MS Access, mais ne parvient pas à Delphes par le biais de la TAdoQuery objet. Mon erreur venait d'un deux-points (excuses à l'affiche originale) à partir d'une valeur de date/heure.

Comme je le comprends, Jet SQL format de date/heure est #mm/jj/aaaa hh:nn:ss# (0 à gauche-rembourrage n'est pas nécessaire).

Si le TAdoQuery.ParamCheck propriété est Vraie, alors ce format échoue. (Merci affiches!) Deux solutions sont: a) de mettre en ParamCheck à Faux, ou b) d'utiliser un autre format de date/heure, à savoir "mm/jj/aaaa hh:nn:ss" (AVEC les guillemets).

J'ai testé ces deux options et ils travaillent tous les deux.

Même si le double-cité format de date/heure n'est pas le Jet format de date/heure, l'Accès est assez bon à faire preuve de souplesse sur ces formats de date/heure. Je pense aussi qu'il a quelque chose à voir avec le BDE/LocalSQL/Paradox (Delphi 7 natif de SQL et de la base de données du moteur) format de date/heure (utilise les guillemets doubles, comme ci-dessus). L'analyseur est probablement conçu pour ignorer les chaînes entre guillemets (les guillemets sont de la chaîne de valeur de délimiteur dans le BDE LocalSQL), mais peut trébucher un peu sur d'autres non-natif des formats de date/heure.

SQL Server utilise des apostrophes pour délimiter les chaînes de caractères, donc c'est peut-être à la place des guillemets lors de l'écriture des tables SQL Server (pas testé). Ou peut-être le Delphi TAdoQuery objet va encore tomber. La désactivation de ParamCheck dans ce cas peut être la seule option. Si vous envisagez de basculer le ParamCheck la valeur de la propriété dans le code, vous économiserez du temps de traitement en assurant la propriété SQL est vide avant de l'activer, si vous ne prévoyez pas sur l'analyse en cours de SQL.

OriginalL'auteur FreeText

Êtes-vous à l'aide de tout le filetage? Il me semble me rappeler comment cette erreur lors d'un événement de minuterie commencé une requête alors que la connexion ADO a été utilisée pour une autre requête synchrone. (La minuterie a été le contrôle d'un "système" drapeau de chaque minute).

OriginalL'auteur Gerry Coll

J'ai aussi eu le même problème, mais avec une dynamique de commande (par exemple, une instruction de mise à Jour).

Certains paramètres peuvent être NULL.

La seule façon que je pouvais obtenir ce travail, a été le paramètre.DataType := ftString et les paramètres.Taille := 1 et pas de réglage de 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;

OriginalL'auteur BennyBechDk

Un seul guillemet double dans la requête peut également soulever cette erreur à partir de ce que j'ai vécu et je ne suis pas à l'aide de paramètres à tous les ...

OriginalL'auteur webnoob

J'ai eu le même message d'erreur. S'est avéré, que c'est parce que l'un des paramètres de la procédure stockée a été déclaré comme étant de type varchar(max). Fait varchar(4000) et l'erreur a disparu.

OriginalL'auteur Kiril Hadjiev