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

C'est une Fonction qui effectue les opérations suivantes:

  • Créer un Jeton aléatoire avec 8 longueur
  • Insérer le Jeton dans la Base de données

  • Si l'Utilisateur a déjà un jeton, une mise à jour.

  • Si l'Utilisateur n'a pas de jeton, l'insérer.

procedure createToken(BenuNr: integer);
var
  AQ_Query:       TADOQuery;
  strToken:       string;
  intZaehler:     integer;
  const cCharSet: string = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
begin
    //Random String as Token
    SetLength(strToken, 8);
  for intZaehler := 1 to 8 do
  begin
    strToken[intZaehler] := cCharSet[1+Random(Length(cCharSet))];
  end;
  //Inserts the Token into the Database
  with AQ_Query do
  begin
    try
      AQ_Query := TADOQuery.Create(nil);
      ConnectionString := strConnectionString;
      SQL.Text := 'if EXISTS(select * from TOKN where BENU_NR = :paramBenu_NR) begin update TOKN set TOKEN = :paramTOKEN where BENU_NR = :paramBenu_NR end else insert into TOKN (BENU_NR, TOKEN) values (:paramBENU_NR,:paramTOKEN)';
      Prepared := true;
      Parameters.ParamByName('paramBENU_NR').DataType := ftInteger;
      Parameters.ParamByName('paramTOKEN').DataType := ftString;
      Parameters.ParamByName('paramBENU_NR').Value := BenuNr;
      Parameters.ParamByName('paramTOKEN').Value := strToken;
      ExecSQL;    //<< Exception as stated in the title
    finally
      Free;
    end;
  end;
end;

De l'exécution de cette me jette à l'exception comme indiqué dans le titre. J'ai coupé l'exemple ci-dessus vers le bas et le tour est joué: plus aucune exception. Malheureusement, je ne comprends pas pourquoi?

procedure createToken();
var
  AQ_Query:     TADOQuery;
  strToken:     string;
  intZaehler:      integer;
  const cCharSet:  string = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
begin
    //Random String as Token
    SetLength(strToken, 8);
  for intZaehler := 1 to 8 do
  begin
    strToken[intZaehler] := cCharSet[1+Random(Length(cCharSet))];
  end;
  //Inserts the Token into the Database
  with AQ_Query do
  begin
    try
      AQ_Query := TADOQuery.Create(nil);
      ConnectionString := strConnectionString;
      SQL.Text := 'update TOKN set TOKEN = :paramTOKEN where BENU_NR = 1';
      Prepared := true;
      Parameters.ParamByName('paramTOKEN').DataType := ftString;
      Parameters.ParamByName('paramTOKEN').Value := strToken;
      ExecSQL;   //<< No more exception
    finally
      Free;
    end;
  end;
end;

Il semble qu'il y a seulement 1 Paramètre autorisé par SQL. Je suis à l'aide de Delphi 7 et MSSQL Server 2005

Une idée de comment résoudre le premier bloc de code pour le faire fonctionner?

Essayez d'utiliser le générateur de profils sql, pour analyser la requête sql.
Sont les noms des paramètres sensibles à la casse? Parce que vous êtes à l'aide de paramBENU_NR lors du réglage du paramètre, mais paramBenu_NR dans le code - et si elles sont sensibles à la casse, c'est probablement de se plaindre parce que vous n'avez pas spécifié une valeur pour le paramètre dans la requête.

OriginalL'auteur Acron | 2009-08-21

  1. 11

    Pour faire ce travail, vous devez utiliser tous les paramètres qu'une seule fois dans la clause SQL. Pour utiliser le même paramètre plus d'une fois il suffit de déclarer avec un nouveau nom. Je ne sais pas pourquoi il en est ainsi, mais je sais qu'il peut être assez ennuyeux.

    Ahh... un des petits avantages de (presque) toujours à l'aide de procédures stockées faire "mise à Jour/Insérer" des requêtes.

    OriginalL'auteur

  2. 2

    J'ai eu la chance d'essayer cela avec un compilateur 🙂 je dois installer un à la maison de temps en temps.

    Alors que j'ai encore à trouver votre utilisation de l'inhabituel, il ne semble pas fonctionner.

    J'ai vu l'erreur que vous obtenez dans plusieurs cas:

    1. Essayez d'exécuter plus d'une requête
      à l'encontre d'une connexion à la fois (à cause du filetage ou d'une minuterie + processMessages)
    2. Avec TADOStoredProc lorsque le nom de procédure est incorrect
    3. Parfois, si l'ADO ne peut pas analyser la requête ne peut pas le tester sans votre base de données de schéma.

    Noter qu'il n'est pas nécessaire dans SQL Server pour définir explicitement le type de paramètre. Ceux-ci sont automatiquement affectées par un événement OnChanged attaché à la SQL objet TStringList.

    Comme un résultat, il est préférable soit de transférer le SQL.Propriété de texte (comme vous le faites), ou si vous l'utilisez .Add('SELECT ...'), utilisez un SQL.BeginUpdate/SQL.EndUpdate paire.

    Réplique originale:

      with AQ_Query do
  begin
    try
      AQ_Query := TADOQuery.Create(nil);
      ConnectionString := strConnectionString;

    Bien que cela semble fonctionner, il semble un peu étrange de se référer à un objet avant de l'instancier.

    AQ_Query doit être instancié avant l'instruction:

      AQ_Query := TADOQuery.Create(nil);
  with AQ_Query do
  begin
    try
      ConnectionString := strConnectionString;

    Mieux encore, ne pas utiliser AVEC - C'est chercher les ennuis.

    Également de noter que la création d'un objet AVANT de l'essayer..enfin. Comme l'écrit que vous auriez un avertissement du compilateur. N'ignorez pas ces - ils vous aider à mieux écrire de code.

    AQ_Query est probablement un jeu de données qui a été créé dans le concepteur de formulaire.
    C'est dans le var, la clause de la procédure CreateToken. Même s'il l'était, réaffectation des il [ AQ_Query := TADOQuery.Create(nil); ] est incorrecte. Création d'objets après un essai est également d'une utilisation incorrecte, sauf s'il a été attribué à nil - vous obtiendrez un "ne peuvent pas être cédés" avertissement "enfin Libre; end;" article.
    Wheeler: Non, cette fonction est entièrement créé dynamiquement. Pas de concepteur.
    Oups. J'ai raté cette ligne.

    OriginalL'auteur Gerry Coll

  3. 1

    Alors que cette erreur est difficile, vous pouvez diagnostiquer il suffit de voir que votre requête est valide. Le problème est dans vos paramètres. La meilleure façon de trouver le vrai problème est de disposer de SQL Server Profiler du suivi de votre base de données lors de la requête. Il va vous montrer la façon dont les paramètres ont été interprétés. Copie de cette requête dans un éditeur de texte pour voir où est ton problème.

    Si vous ne parvenez pas à utiliser générateur de profils SQL Server, vous devez juste sortie les valeurs "BenuNr" et "strToken" à l'écran ou de la console de sorte que vous pouvez vraiment voir ce que vous êtes de passage en paramètres.

    OriginalL'auteur Steven Hook

  4. 1

    Jusqu'à maintenant, je n'ai pas de résoudre le problème.

    Mais je suppose que le problème se situe quelque part à l'intérieur de l'Paramètres et la manière d'y accéder. Le compilateur prend en indice, pas de nom comme je présume.

    Avoir un oeil de plus près à la TADOQuery Composant dans l'OI (surtout à la TParameters section), vous pouvez voir que les index.

    À la fin, il probaply neccecary d'abord, ajoutez un paramètre, de lui donner un nom, puis insérez une valeur, ou quelque chose comme ça.

    Pour ce que ça vaut: j'ai juste eu cette erreur et il fixe. J'ai traqué j'ai été l'affectation d'un paramètre Value avec une variante de la valeur de VarType varEmpty. À l'aide de Null au lieu fixe.

    OriginalL'auteur Acron

  5. 1

    Éteindre le préparer. Set préparé=False sur le composant d'ADO. Il semble que le serveur est seeingn avant les deux paramètres existent, et la préparation (la compilation). Lorsque vous exécutez avec deux paramètres, le paramètre de la liste ne correspond pas à la déclaration préparée.

    OriginalL'auteur cthompson

  6. 0

    Ouch. Vous venez de frapper ce que notre système d'architecte au travail appelle "la pire erreur jamais". C'est une jolie erreur générique et peut signifier toutes sortes de choses. Mais je ne l'ai jamais vu ça sur des instructions INSERT, alors essayez de regarder. Il est provoqué par la définition que l'ADO n'est pas correspondant au schéma de base de données d'une certaine façon.

    Essayez de réduire votre requête pour l'insérer et d'utiliser le générateur de profils SQL inclus avec SQL Management Studio pour regarder ce que l'ADO est en train de faire lorsqu'il se déclenche. Il aurez plus de chances de demander pour la structure de votre tableau, de la comparer à l'encontre de la structure de votre déclaration, et à la fin de ne pas aimer ce qu'il trouve, et jamais réellement l'envoi de la commande INSÉRER à la base de données.

    Assurez-vous que vous avez les bons types de données dans les champs, et que vous pouvez exécuter avec succès une INSERTION dans la table en utilisant simplement ces deux valeurs. Qui pourraient ne pas fonctionner--ce est la pire erreur jamais, après tout -, mais elle devrait vous donner un point de départ.

    OriginalL'auteur Mason Wheeler

  7. 0

    Vous n'avez pas besoin de spécifier DataType. Après un appel réussi à Prepare; les paramètres doivent être configurés correctement sur le serveur de la définition de la table.

    Ma conjecture est que par l'affectation de DataType, le paramètre est probablement de réinitialisation et de l'information est manquante, par exemple, ParamType devrait être ptInput mais est remis à ptUnknown ou quelque chose comme ça.

    Essayez de supprimer les lignes dont vous définissez le Type de données et voir si ça aide.

    OriginalL'auteur Ondrej Kelle

  8. 0

    Pour moi, cette erreur vient sans paramètres, lorsque le (sinon tout à fait valable) instruction SQL contenues varchar valeur littérale avec un deux-points (:) à l'intérieur d'une cité sous-texte. E. g.

    UPDATE ... SET myfield = 'foo " :bar "'

    La solution peut être de passer à des paramètres de laid intégré littéraux. Je n'ai pas trouvé d'autre solution encore.

    OriginalL'auteur Gaspar Nagy