RemoteDB XDataSet Business Logic

Wagner


Here's a interesting Business logic from "ASTA" I will want you to develop for RemoteDB.

On Asta we have the ability to create a temporary dataset with any number of input/output parameters so clients can call the "Method" and execute something.

I know you will redirect me to create such funcionality with XData but this Asta technique will be excellent if you add to RemoteDB features because it's completely GUI based.

Once a RemoteDB user is authorized to access the DB remotely then we can use this type of component.

Check the image and the code below so you can understand.




--------------------------------------------------
procedure TAstaDataModule.CambiaDeStatusRFCActions0Action(Sender: TObject;
  ADataSet: TDataSet; ClientParams: TAstaParamList);
Var
     ResultadoCambiaStatusFINKOKRFC: RegistrationResult;
     Enlace: THTTPRIO;
begin
     // Ejecutamos la inserción del RFC como socio de negocio
     CoInitialize(nil);

     // Consultamos los timbres del RFC solicitado
     Log('Cambiando Status ' + ClientParams.ParamByName('Status').AsString + ' al RFC ' + ClientParams.ParamByName('Rfc').AsString);

     ClientParams.ParamByName('Resultado').AsBoolean := False;
     ClientParams.ParamByName('Error').AsString := EmptyStr;

     // Se invoca el Webservice sin taxpayer para que devuelva TODOS aquellos que cumplen con el rango de fechas
     Try
          ResultadoCambiaStatusFINKOKRFC := GetApplicationRegistro.edit('', '', ClientParams.ParamByName('Rfc').AsString, ClientParams.ParamByName('Status').AsString, Nil, Nil, EmptyStr);

          // Retornamos los valores
          ClientParams.ParamByName('Resultado').AsBoolean := ResultadoCambiaStatusFINKOKRFC.success;
          ClientParams.ParamByName('Error').AsString := ResultadoCambiaStatusFINKOKRFC.message;

          // Si fué exitosa la asignación introducimos los valores
          If ResultadoCambiaStatusFINKOKRFC.success then
          Begin
               With QueryCambiaStatusRFC do
               Begin
                    Close;
                    ParamByName('Usuario').AsInteger := ClientParams.ParamByName('Usuario').AsInteger;
                    If ClientParams.ParamByName('Status').AsString = 'A' then ParamByName('Status').AsBoolean := True Else ParamByName('Status').AsBoolean := False;
                    ParamByName('Rfc').AsString := ClientParams.ParamByName('Rfc').AsString;
                    ExecSQL;
               End;
          End;
     Except
          ClientParams.ParamByName('Error').AsString := 'Error en la comunicación con el PAC.';
     End;
end;


Indeed, XData is the way to go. I don't see a reason to backport an existing feature to an "older" way of using it? In XData you call the method using interfaces, checking error and types at compile time:



Results := Service.XDataMethod(Param1, Param2);


Wagner

You're not seeing the big picture, people are lax, they don't want to code as in old fashion "ms-dos" they want GUI interfaces in order to to his tasks. After all WYSIWYG was invented a very long time.

If you create a component for provide services people will love it and use it on design time.

I understand that. It's a valid point and interesting feature, but it's not something that will add functionality, it will just provide a different way of doing the same feature.