Hi All,

As someone who used the old DBISAM OnServerProcedure I've been excited
to be able to use this same function in EDB.

I'm having trouble implementing it and have been reading the manual /
playing around and still can't get it to work.

I'm not sure if I'm getting confused with the TParamType that's now
involved or if there's another problem, but I get an EDB #1011 error. An
error occurred with the value F (A conversion error occurred).

All the code below appear to work, the "LicenseCommand" is passed and
the LicenseProcedure name is also passed, I've checked this by
displaying the variables on in the client program, its after it leaves
the OnServerProcedure that the problem occurs.

I call the procedure from my client program using the following...

DM->CDSSession->RemoteParams->CreateParam(ftInteger,"LicenseCommand",
ptOutput)->AsInteger = 1;
DM->CDSSession->CallRemoteProcedure("LicenseProcedure");

// Set GLOBAL vars to values sent back from server
DM->L_Mode =
DM->CDSSession->RemoteParams->ParamByName("LicenseMode")->AsString;
DM->L_Key =
DM->CDSSession->RemoteParams->ParamByName("LicenseKey")->AsString;
DM->L_Expiry =
DM->CDSSession->RemoteParams->ParamByName("LicenseExpiry")->AsString;
DM->L_User =
DM->CDSSession->RemoteParams->ParamByName("LicenseUser")->AsString;


And Code on the server side..........

void __fastcall TMain::ServerEngineServerProcedure(TObject *Sender,
const TEDBServerProcedure *ServerProcedure)
{
  if (ServerProcedure->Name == "LicenseProcedure")

  LicenseCommand =
ServerProcedure->Params->ParamByName("LicenseCommand")->AsInteger;

  ServerProcedure->Params->Clear();

  if (LicenseCommand == 1)
  {
    ServerProcedure->Params->CreateParam(ftString,"LicenseMode",
ptOutput)->AsString = L_Mode;
    ServerProcedure->Params->CreateParam(ftString,"LicenseKey",
ptOutput)->AsString = L_Key;
    ServerProcedure->Params->CreateParam(ftString,"LicenseExpiry",
ptOutput)->AsString = L_Expiry;
    ServerProcedure->Params->CreateParam(ftString,"LicenseUser",
ptOutput)->AsString = L_User;
  }
}

Phil,

> I'm not sure if I'm getting confused with the TParamType that's now
involved or if there's another problem, but I get an EDB #1011 error. An
error occurred with the value F (A conversion error occurred).

I'm not positive, but I think that this is a bug.  Returning an integer
value works just fine, but attempting to push a string back to an output
parameter appears to be a problem.


--
---------------------------------------
Terry Swiers
Millennium Software, Inc.
http://www.1000years.com
http://www.atrex.com

Gift Card Processing - Now available in Atrex 13

Atrex Electronic Support Options:
Atrex Knowledgebase: http://support.atrex.com/KB/root.aspx
Email: support@atrex.com
Newsgroup: news://news.1000years.com/millennium.atrex
Fax: 1-925-829-1851
Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
---------------------------------------

> I'm not positive, but I think that this is a bug.  Returning an integer
> value works just fine, but attempting to push a string back to an output
> parameter appears to be a problem.

Thanks Terry, that's what I'm thinking.

OK I've worked it out...

I was doing this based on the original DBISAM, but there are few rules
in the EDB equivalent.

TEDBServerProcedure.Params Property

*Do not add or delete parameters, or change their name, using this
property. The parameters that are sent by the calling remote session
should be left as-is. Any result or output parameters required by the
calling remote session will be marked as such (ptInputOutput, ptOutput,
or ptResult) via their ParamType property.

ALSO... I changed the parameter to use ftWideString as it was probably
having trouble with UnicodeString

So in effect I setup ALL the parameters in the calling remote session,
then just read / set the parameters values to be passed back.


Client side
-----------

DM->CDSSession->RemoteParams->Clear();
      DM->CDSSession->RemoteParams->CreateParam(ftInteger,"LicenseCommand",
ptInput)->AsInteger = 1;
      DM->CDSSession->RemoteParams->CreateParam(ftWideString,"LicenseMode",
ptOutput);

......................................

Server side
-----------

void __fastcall TMain::ServerEngineServerProcedure(TObject *Sender,
const TEDBServerProcedure *ServerProcedure)
{
  ServerProcedure->Params->ParamByName("LicenseMode")->AsWideString =
"TEST";
}

Hi Phil,

> *Do not add or delete parameters, or change their name, using this
> property.

I knew about this restriction from the documentation and was leaving
everything as it was created from the requesting side.


> ALSO... I changed the parameter to use ftWideString as it was probably
> having trouble with UnicodeString

Now THIS made all of the difference in the world.  If I leave the parameter
type as ftString, I get the conversion error.  If I change the type of the
parameter to ftWideString, it works exactly as expected.

Thanks for the pointer in the right direction.


--
---------------------------------------
Terry Swiers
Millennium Software, Inc.
http://www.1000years.com
http://www.atrex.com

Gift Card Processing - Now available in Atrex 13

Atrex Electronic Support Options:
Atrex Knowledgebase: http://support.atrex.com/KB/root.aspx
Email: support@atrex.com
Newsgroup: news://news.1000years.com/millennium.atrex
Fax: 1-925-829-1851
Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
---------------------------------------

Terry,

<< Now THIS made all of the difference in the world.  If I leave the
parameter type as ftString, I get the conversion error.  If I change the
type of the parameter to ftWideString, it works exactly as expected. >>

Yep, you have to use ftWideString and ftWideMemo with the Unicode version.
With parameters I could probably relax this and allow for ftString/ftMemo,
but it would confuse the issue when it comes to dataset fields so I have
been avoiding doing so.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Tim while your here on the subject... I just wanted to say a BIG thanks
for adding this feature!!!

Phil,

<< Tim while your here on the subject... I just wanted to say a BIG thanks
for adding this feature!!! >>

No problem, sorry it took so long to get it out the door.

Tim Young
Elevate Software
www.elevatesoft.com