Custom RDD

[leon-ts]

Hi,

I am starting to transport the custom driver that we in our team developed to simulate the operation of RDD DBFCDX with MS SQL. This driver fully imitates the operation of DBFCDX, but with the database on a SQL Server. XSharp has a different approach to writing RDD than VO. I see that I need to rewrite my RDD to a class. The question is: from which class do I need to inherit my class?

Best regards,
Leonid

[robert]

Leonid,
You don't really need to inherit from a class as long as your class implements XSharp.RDD.IRdd.
But you may want to inherit from XSharp.RDD.Workarea.
See https://github.com/X-Sharp/XSharpPublic ... rkarea.prg.
This class has some properties and method implementations that you may want to use.

Robert

[leon-ts]

Robert, thanks for the tip!

In RDD for VO, there are common functions that do not directly depend on DBFCDX, and we did not program their implementation, but left the default implementation from Host RDD. Therefore, in XSharp, I need to inherit my class from some class that already has a basic common implementation. I will look at XSharp.RDD.Workarea. Thanks!

Best regards,
Leonid

[leon-ts]

Hi to all,

Is there any point in XSharp (as opposed to VO) passing an RddList list to UseArea instead of a single name, such as "DBFCDX"?

In VO for DBFCDX, we passed a list of three elements based on the following hierarchy:
CAVODBF
_DBFCDX
DBFCDX

I looked at the Runtime sources in XSharpPublic and didn’t understand if this makes any sense now?

Also, my colleague conducted an experiment in XSharp with passing only "DBFCDX" strings to UseArea instead of RddList (with three names, as in VO), and it worked great.

Best regards,
Leonid

[robert]

Leonid,

The RDDList is no longer required (but supported).

Robert

[leon-ts]

Robert,

Thanks for info!

Best regards,
Leonid

[leon-ts]

Robert,

I am almost finishing transporting my SqlRdd from VO to XSharp. At your advice, I inherited it from the Workarea class, which implements the basic functionality (it was also in VO). But it bothers me that some members of the Workarea class, which by their nature must be protected, are public. For example: _Area, _FileName, _Fields, _BoF, _EoF, etc. (in principle, all members whose name begins with an underscore). It is correct? Indeed, in this way these members can be changed externally, which violates the logic of the driver.

Best regards,
Leonid

[leon-ts]

Addition:

In the IRdd interface and in the Workarea class in the Lock() method, a typo is possible in the name of the uiMode parameter (copy/paste from the previous HeaderLock method).

Code: Select all

METHOD Lock(uiMode REF DbLockInfo) AS LOGIC

Most likely, it should have a name not uiMode, but lockInfo (this is the name of this parameter in your DBF class).

Best regards,
Leonid

[robert]

Leonid,
Thanks for your remarks.
I will rename the parameter in the Lock method.
The fields were made public for simplicity, but you are right they should probably be replaced with properties, maybe with a public getter and a private or protected setter.
I can do that for the next build, but that will also require you to change your code.

Robert

[leon-ts]

Robert, thanks!

It will be great if the mentioned members of the Workarea class have an access modifier - protected. In this case, derived classes such as DBFCDX, DBFNTX and so on, including my SqlRdd, will have direct access to them without a setter layer. This will provide good performance and at the same time close access to them from the outside.

Best regards,
Leonid