Delphi，FireDAC和自定义登录顺序

Question

Using FireDac with SQL Server. For a program where I manage a databasconnection (and thus not always has a database to connect to from the beginning), I want this to happen:

1. The user connects and the OnLogin event is triggered.
2. First I want to try default values/values from a settings file
3. If that fails due to wrong user_name/password I want to show a password dialog
4. Repeat step 3. until login ok or user cancels.

There is some handling of a similar scenario in FireDacs own logindialog, but it seems very complex and the dialog is ugly (I would lika my own!), and also doesn't have a checkbox for "Use OS authentication" that I would need.

Any hints would be great!

/Anders

Answer 1

If you don't want to make a TFDGUIxLoginDialog dialog descendant, you can simply write a loop in which you'll be trying to open the connection handling EFDDBEngineException exception, and asking its Kind for ekUserPwdInvalid (optionally ekUserPwdExpired , or ekUserPwdWillExpire when you need to). Without the OnLogin event handler it can be something like this:

procedure TForm1.Button1Click(Sender: TObject);
var
  LoginDialog: TMyLoginDialog;
begin
  { ← assign parameters from config file here }
  while True do
  try
    FDConnection.Open; { ← try to connect }
  except
    on E: EFDDBEngineException do
      case E.Kind of
        ekUserPwdInvalid: { ← here you can show your login dialog }
        begin
          LoginDialog := TMyLoginDialog.Create(nil);
          try
            if LoginDialog.ShowModal = mrOk then
            begin
              { ← assign parameters from login dialog here }
            end
            else
              raise; { ← user cancelled login dialog }
          finally
            LoginDialog.Free;
          end;
        end;
        ekUserPwdExpired: { here you can show password change dialog };
        ekUserPwdWillExpire: { here you can optionally show password change dialog };
      else
        raise;
      end;
    else
      raise;
  end;
end;

The OnError event is no good for this task because there's no way to eat the exception from there. If you release the exception object there (to pretend login was successful and let the engine fail on something else for reconnect attempt), you may get unpredicted behavior (so as when you modify the exception object in a bad way ).