FiveTech Software tech support forums

... the paste. Thank you so much for that answer. It also explains why I could not duplicate the problem here. I know to click on the left side ( by habit ) and do my paste. Tim

... )" than "HDATE <= (date)", because many RDBMS use datetime fields. How to easily generate these expressions? We better make it a habit to open an ADO connection using FW_OpenAdoConnection() of FWH instead of opening on our own with ADODB.Connection. If we open using FWH function ...

I wonder... (Antonio, ChatGPT is not accessible, to much hits at this time ))))) When a dbf is on a record I have the (BAD) habit of doing calculations like : nAankoop = artikel->new_bruto - (artikel->new_bruto * artikel->korting)/100 nAankoop = nAankoop - (new_bruto * artikel->korting2)/100 ...

Enrico,

That works fine. I guess I was just working from habit with the older versions. I just tested to be sure.

Tim

Thanks Antonio, now works fine.

Use uppercase for preprocessed keywords only (my advise)

Interesting point for a good technical discussion. My former editor does this almost automatically, it has become a habit. But I see no problem with making a general change, if there are benefits.
Thankful,

Code: Select all  Expand view

function bCampo2( aFields, nFor,oDbf)
return fieldWBlock( aField[nFor], oDbf:nArea )
 

I still advise you to use the sample I posted and please change your habit.

Add the clause NOBORDER to XBROWSE command, whenever you create from sourcecode. Just make it a habit to use always. (Not for resources) On bottom and right, you see the border drawn by lDrawBorder when HScroll and VScroll are absent. https://imagizer.imageshack.com/v2/xq90/923/KOSRtP.png

... till '2015-04-30 23:59:59.999' This is just an example to show how deceptive can be date comparisons. In addition MS Sql server has a very awkward habit of storing '2014-04-01' internally as '2014-04-01 12:00:00' in the field. So, the safer construct is SELECT * WHERE INVDT >= '2015-04-01' AND ...

... in maintaining the SQL Table and at the same time gives the programmer the same experience as we handle DBF tables. ( If we give up the old habit of directly using bStrdata, etc ) TDataRow: Same way like XBrowse the values are padded for editing and trimmed for storing. TRecSet (new class) ...

... Meanwhile please let us know: a) Approx size of the DBF ( number or records ) b) Does the DBF contain many deleted records? c) Do you have the habit of creating an index tag on DELETED() and setting filter to "!DELETED()" ? Notes on point (c): If we set filter to "!DELETED()", ...

... to refer to oRs in program code, it is always better to use oBrw:oRs Example Instead of oRs:fields( 2 ):Value Use oBrw:oRs:Fields( 2 ):Value This habit of coding enables swithing oRs at runtime easier. 3. As far as possible, you may use built in edit features of xbrowse. I can advise better if ...

... all field names in the select clause. Sad no DBMS, except MSACESS provides this automatic feature. Any way, provided you do not make it a habit, you can tolerate the duplicate field names in the recordset and it does not hurt you much if you take some precautions like refer to fields by ...

... also. So, better to avoid BETWEEN for dates. Use " field >= d1 and field < ( d2 + 1 ) When we move on to RDMSs, we better make it a habit to think that the date-fields can contain time part also.

Thank you. I think that MS still continue with its bad habit of reinventing the wheel to include some custom extension. Something like C++ smart pointers would be enough.

EMG

Tim,

yes, one of the most important aspect is the lack of time, that's hiding behind my first reason 'By habit'.