CODEWITHSUNDEEP
sqldelphims-access
Sdean
Sdean

Reputation: 247

delphi has ExecSQL succeeded or failed

Hello i've this function to update my Access DB using TUniQuery :

var
  Res:Boolean;
begin
Res:=false;
  try
  with MyQuery do
  begin
    Active := false;
    SQL.Clear;
    SQL.Add('Update MYTABLE');
    SQL.Add('set username='+QuotedStr(NewUserName));
    SQL.Add(',password='+QuotedStr(NewPassword));
    SQL.Add('where username='+QuotedStr(ACurrentUserName));
    ExecSQL;
    Res:=true;
  end;
  except
  Res:=False;
  end ;
  Result:=Res;
end;

Is the use of Try ... except enough to KNOW when " ExecSQL " succeeds or fails ?

or is there any other better approach ?

thank you

Upvotes: 3

Views: 13720

Answers (1)

jachguate
jachguate

Reputation: 17203

You may want to consider your update succeeded if no exception is raised. It means the database is responsive and parsed and executed your statement without syntax errors.

In a statement like shown, you may also want to be sure that exactly one row was updated, because I assume that's your intention.

To check that, you can resort to the result of the ExecSQL method, which returns the number of rows affected by the execution of the statement. So, you may change your code to this:

begin
  with MyQuery do
  begin
    Active := false;
    SQL.Clear;
    SQL.Add('Update MYTABLE');
    SQL.Add('set username='+QuotedStr(NewUserName));
    SQL.Add(',password='+QuotedStr(NewPassword));
    SQL.Add('where username='+QuotedStr(ACurrentUserName));
    Result := ExecSQL = 1; //exactly 1 row updated
  end;
end;

I also changed the unconditional exception handler, since it may not be the proper site to eat any exception, and also removed the local variable to store the Result, since that really is not necessary.

After reading your added text and re-thinking your question:

Is the use of Try ... except enough to KNOW when " ExecSQL " succeeds or fails ?

You really have to change your mind about exception handling and returning a boolean from this routine. Exceptions were introduced as a whole new concept on how to address exceptional and error situations on your programs, but you're killing this whole new (and IMHO better) approach and resorting to the old way to return a value indicating success or failure.

Particularly a try/exception block that eats any exception is a bad practice, since you will be killing exceptions that may be raised for too many reasons: out of memory, network problems like connection lost to database, etc.

You have to re-think your approach and handle these exceptional or error conditions at the appropriate level on your application.

My advise is:

  • change this from a function to a procedure, the new contract is: it returns only if succeded, otherwise an exception is raised.
  • if an exception occurs let it fly out of the routine and handle that situation elsewhere
  • raise your own exception in case no exactly 1 row is updated
  • change the query to use parameters (avoiding sql injection)

The routine may look like this:

procedure TMySecurityManager.ChangeUserNameAndPassword();
begin
  MyQuery.SQL.Text := 'Update MYTABLE'
              + '   set username = :NewUserName'
              + '       , password = :NewPassword'
              + ' where username = :username';
  MyQuery.Params.ParamByName('NewUserName').AsString := NewUserName;
  MyQuery.Params.ParamByName('NewPassword').AsString := NewPassword;
  MyQuery.Params.ParamByName('username').AsString := ACurrentUserName;
  if MyQuery.ExecSQL <> 1 then
      raise EUpdateFailed.Create('A internal error occurred while updating the username and password');
  //EUpdateFailed is a hypotetical exception class you defined.
end;

Upvotes: 10

Related Questions