L'utilisation de paramètres avec ADO Requête (mysql/MyConnector)

Je voudrais essayer d'ajouter SQL.BeginUpdate/SQL.EndUpdate autour du Ajoute, sinon le texte SQL sera analysé chaque fois que vous appelez "Ajouter".

C'est généralement une bonne idée, car ADOQuery.SQL est un TStringList qui a un événement OnChange qui définit la CommandText. SetCommandText du texte, puis retrouvez l'appel TADOCommand.AssignCommandText qui fait un travail d'analyse params, et la mise CommandObject.CommandText. Parfois, les pilotes de l'échec partiel des instructions SQL, mais ça semble OK.

J'ai eu un problème similaire il y a plusieurs années, c'est pourquoi j'ai appris beaucoup sur ce genre de choses!

procedure TForm1.login();
var
  Qry : TADOQuery;
begin
  Qry := CreateSQL;
  try
    Qry.SQL.BeginUpdate;

    Qry.SQL.Add('SELECT');
    Qry.SQL.Add('  *');
    Qry.SQL.Add('FROM');
    Qry.SQL.Add('  LisenswebUsers');
    Qry.SQL.Add('WHERE UserName = :MyUsername '); //debugger exception here
    Qry.SQL.Add('  AND UserPassword = :MyPassword '); //debugger exception here

    Qry.SQL.EndUpdate;
    Qry.Parameters.ParamByName('MyUsername').value := txtLogin.text;
    Qry.Parameters.ParamByName('MyPassword').value := strmd5(txtPassword.text);
    Qry.Open;

    if Qry.Recordcount <> 1 then
    begin
      lblLoggedinAs.Text := format('Du er logget inn som: %s (%s)',[FieldByName('Username').AsString,FieldByName('UserEmailaddress').AsString]);
      MainPageControl.ActivePageIndex := 1;
    end
    else
    begin
      txtPassword.Text := '';
      txtPassword.SetFocus;
    end;
  finally
    Qry.Free;
  end;
end;

BTW, le imbriquée withs sont vraiment laid (laissez le saint-guerre commencer)

Je vais parfois utiliser with, mais ne serait jamais le nid trois niveaux! Si vous êtes, au moins, de réduire le champ d'application de SQL de sorte qu'il se termine avant avec des Paramètres.

OriginalL'auteur Gerry Coll

Dans mon cas, la définition des paramètres et de l'affectation de la chaîne de requête avant de l'affectation de la connexion corrigé le problème. La requête s'exécute avec succès dans les deux cas, mais la TADOQuery composante interne de la pose (et par la suite les hirondelles) le EOleException noté dans l'OP si la connexion est donné avant que la requête paramétrée.

//LADOQuery.Connection := LADOConnection;  //Exception @ LADOQuery.Text:=...

Param := LADOQuery.Parameters.AddParameter;
Param.Name := 'rid';
Param.DataType := ftFixedChar;
Param := LADOQuery.Parameters.AddParameter;
Param.Name := 'qd';
Param.DataType := ftLongWord;

LADOQuery.SQL.Clear;
LADOQuery.SQL.Text:='SELECT Val FROM table WHERE v1=:rid AND v2=:qd';

LADOQuery.Connection := LADOConnection;  //OK!

Je suis ouvert à des explications pourquoi c'est le cas, rien dans la documentation semble indiquer un besoin de cet ordre des opérations.

L'exception est soulevée dans ADODB.pas dans TADOCommand.AssignCommandText ici

 try
   //Retrieve additional parameter info from the server if supported 
   Parameters.InternalRefresh; 

où cette branche est la seule à suivre si le TADOQuery est attaché à une connexion en direct. InternalRefresh effectue :

if OLEDBParameters.GetParameterInfo(ParamCount, 
                                    PDBPARAMINFO(ParamInfo), 
                                    @NamesBuffer) = S_OK then
  for I := 0 to ParamCount - 1 do
    with ParamInfo[I] do
    begin
      //When no default name, fabricate one like ADO does 
      if pwszName = nil then
      Name := 'Param' + IntToStr(I+1) else //Do not localize 
      Name := pwszName;
      //ADO maps DBTYPE_BYTES to adVarBinary 
      if wType = DBTYPE_BYTES then wType := adVarBinary;
      //ADO maps DBTYPE_STR to adVarChar 
      if wType = DBTYPE_STR then wType := adVarChar;
      //ADO maps DBTYPE_WSTR to adVarWChar 
      if wType = DBTYPE_WSTR then wType := adVarWChar;
      Direction := dwFlags and $F;
      //Verify that the Direction is initialized 
      if Direction = adParamUnknown then Direction := adParamInput;
      Parameter := Command.CommandObject.CreateParameter(Name, wType, Direction, ulParamSize, EmptyParam);
      Parameter.Precision := bPrecision;
      Parameter.NumericScale := ParamInfo[I].bScale;
      //EOleException raised here  vvvvvvvvv
      Parameter.Attributes := dwFlags and $FFFFFFF0; //Mask out Input/Output flags 
      AddParameter.FParameter := Parameter;
    end;

Le problème semble être à l'OLE niveau, probablement parce que le pilote ODBC de MySQL ne prend pas en charge le retour de cette information (ou retourne des informations non valides). L'exception est levée derrière la _Parameter de l'interface lors de la configuration de

 Parameter.Attributes := dwFlags and $FFFFFFF0; 

à l'aide de ce qui semble être des valeurs non valides (dwFlags = 320 -> les bits définis ci-dessus DBPARAMFLAGSENUM durée définie) retour d' GetParameterInfo. La gestion des exceptions pour le contrôle de flux semble la seule option étant donné que l'interface ne fournit aucun mécanisme pour vérifier les valeurs avant de les mettre (et de déclencher des exceptions).

---

Mise à jour :

Il s'avère qu'il y est un ouvert QC à ce sujet : http://qc.embarcadero.com/wc/qcmain.aspx?d=107267

OriginalL'auteur J...