xBrowse & SELECT parameter

[Euclides]

I am working in conversion of old FW & Clipper systems.
I just discovered that the SELECT clause in REDEFINE XBROWSE is accepted but not processed. (I tested with several FWH versions)
Discovered also that oBrw:SetFilter("field", <field>) does not exist in xBrowse.
In this case, there are NTX index files. (cannot use ordscope).
Any suggestions?
TIA Euclides.

[nageswaragunupudi]

This feature is not available in XBrowse.

[Euclides]

Hi, sorry for hearing that... In this case, I suggest to elininate the line:

Code: Select all  Expand view

[ SELECT <cField> FOR <uValue1> [ TO <uValue2> ] ] ;
 

from the DEFINE & REDEFINE statements in th XBROWSE.CH
I will keep using TWBROWSE
Regards, Euclides

[nageswaragunupudi]

It is your choice to use xbrowse or wbrowse.

We did not implement in xbrowse because now ORDSCOPE() works for DBFNTX also and this is a lot better than implementation inside browse logic.

ORDSCOPE( 0, "B" )
ORDSCOPE( 1, "D" )
GO TOP

and XBrowse.
This is quite efficient

[James Bott]

You should consider moving to CDXs--they all exist in one file and you can globally set them to open automatically whenever you open the DBF.

Better yet, you should consider moving to database objects--no more using aliases or work areas. You can eliminate lots of code this way. This provides easier to read code with less bugs, and it is easier to maintain.

oCustomer:= TCustomer():New( cCustNo )

msgInfo( oCustomer:balance() )

How easy is that?

[nageswaragunupudi]

You should consider moving to CDXs--they all exist in one file and you can globally set them to open automatically whenever you open the DBF.

Better yet, you should consider moving to database objects--no more using aliases or work areas. You can eliminate lots of code this way. This provides easier to read code with less bugs, and it is easier to maintain.

oCustomer:= TCustomer():New( cCustNo )

msgInfo( oCustomer:balance() )

How easy is that?

Mr James.
Your advise is good. But every programmer here has already running applications with large code. It is not so easy to convert the entire project to oops or even converting from ntx to cdx.

They need simple solution to work without undertaking a major change.

Using OrdScope() is much simpler for dbfntx also.

I am considering why not we translate the SELECT .... clause in xbrowse to apply OrdScope() inside the xbrowse.prg which makes it easier for migration from wbrowse to xbrowse. May be we provide this in the next release.

[Euclides]

Thanks Mr.Rao. I was not aware about using ORDSCOPE with DBFNTX.
But let me insist...
in XBROWSE.CH, in the statement #xcommand:
#xcommand @ <nRow>, <nCol> [ COLUMN ] XBROWSE <oBrw> ;
... the line:
[ SELECT <cField> FOR <uValue1> [ TO <uValue2> ] ] ;
should be deleted
Your thougths please...
Regards, Euclides

[Euclides]

Hi James, thanks for the info...
As I stated in the beggining, I am converting an old FiveWin-Clipper app.
I used (until today in smal systems) to load the DBF into an Array and after the dialog, load it back to DBF (scatter & gather functions).
Would be a lot of work rewrite it to use TDatabase
In the newest systems, I am using TDatabase extesively.
Regards, Euclides

[nageswaragunupudi]

For your information, class TDataRow is created to be used in the place of scatter/gather logic, but this class is robust and safer. We can also address the fieldnames as oRec:fieldname.

TDataRow works with DBF, TDatabase, ADO Recordset, TRecSet, DolphinQry exactly the same way.

[Euclides]

Thanks Mr. Rao
Regards, Euclides

[bpd2000]

For your information, class TDataRow is created to be used in the place of scatter/gather logic, but this class is robust and safer. We can also address the fieldnames as oRec:fieldname.

TDataRow works with DBF, TDatabase, ADO Recordset, TRecSet, DolphinQry exactly the same way.

Nice for info
Dear Rao,
Any link / working small example, please