XHARBOUR , ADO , ANSI and OEM

[Franklin Demont]

Hello ,

FWH 14.04 , using functions from adofunc to make connection and open table , xharbour fail's in ANSI code

According to this forum i changed the register as described in one from the thread's.

Using harbour i have no problems

FRank

[nageswaragunupudi]

xharbour fail's in ANSI code

Can you please explain in greater detail?

[Franklin Demont]

xharbour fail's in ANSI code

Can you please explain in greater detail?

My code :

oCon := FW_OpenAdoConnection( cFilName )
cTable = FW_QuotedColSQL( cTable )
cSql := "SELECT " + cFields + " FROM " + cTable
IF VALTYPE(cWhere) == "C"
cSql += cWhere
END
oRs := FW_OpenRecordSet( AdoCon , cSql , 3 , 1 ) //, nLockType, nCursorType, nMaxRecords, nOpt )
oRs:Find("ID='11'") // The third character from field gemeente is CHR(201) , É
?? ASC(oRs:Fields("Gemeente"):Value[3]) // XHARBOUR gives 42 (+) , HARBOUR gives as expected 201 (É)


All codes with ASC value > 127 are bad , ansi characters are not recognised.

It is the only problem i have with xharbour.

When i try to compile in harbour i have other problems :

1) oGet:oGet:Changed doesn't work at all in harbour , gives always falls
2) AT this moment Harbour fails on a expression as oRs:Sort(cColumn)
I am sure that oRs is correct ( Controled with FWDBG) and cColumn exists as field in ors

I will start today with a new thread. Maybe is the code which i am writing (comboclass for arrays with multiple columns or ADO recordset) usefull for others to

Frank

[nageswaragunupudi]

Thanks for the info. My experience is limited to databases with pure English only and I never had to opportunity to recognize this issue.

2) AT this moment Harbour fails on a expression as oRs:Sort(cColumn)

Please always use "oRs:Sort := <columns>" but not "oRs:Sort( <columns> )", whether it is xHarbour or Harbour. Same way with oRs:Filter := <expression>. This is the correct ADO syntax. In some versions of [x]Harbour, "oRs:Sort( <value>)" might have worked but we can not assume that this *has* to work.

I will start today with a new thread. Maybe is the code which i am writing (comboclass for arrays with multiple columns or ADO recordset) usefull for others to

That is nice.
But this is just for your information that FWH will soon be coming up with Get linked to xbrowse (visible only when Get is used). Not in 14.06 but in the subsequent version.

[nageswaragunupudi]

I have done some tests on the ANSI characters ( > 128 ) issue. What I have observed is that xHarbour reads correctly what is written by xHarbour and Harbour reads correctly what is written by Harbour.

We can test this by this small program.

Code: Select all  Expand view

#include "fivewin.ch"
#include "adodef.ch"

function Main()

   local oCn, oRs
   local cVal, cRead

   cVal     := "Zürich"
   ? Asc( SubStr( cVal, 2, 1 ) )

   oCn   := FW_OpenAdoConnection( "c:\fwh\samples\xbrtest.mdb" )

   oRs   := FW_OpenRecordSet( oCn, "CUSTOMER" )
   if MsgYesNo( "Write?" )
      oRs:Fields( "City" ):Value    := cVal
      oRs:Update()
   endif
   oRs:Close()
   oRs   := FW_OpenRecordSet( oCn, "CUSTOMER" )
   cRead := oRs:Fields( "City" ):Value
   ? cRead, cRead == cVal, Asc( SubStr( cRead, 2, 1 ) )
   oRs:Close()
   oCn:Close()

return nil
 

We can test with xHarbour and Harbour separately. What is written by xHarbour is read correctly by xHarbour but not Harbour and vice versa.

This is not acceptable to us. What is written either in xHarour or Harbour should be read by other and most importantly by MSAccess Application. Also the data should be read correctly by 3rd party applications using other languages. Our applications should read correctly data obtained from 3rd parties.

First if we test with MSACCESS on desktop, MSAccess correctly reads the data written by xHarbour but NOT Harbour. I have tested with MSAccess 2010 with default settings.

After experimenting further what I found is that xHarbour, as it is, compatible with MSACCESS and surely must be with all 3rd party apps. If we use Harbour, we need to convert the value with AnsiToOem while writing and reverse the process while reading.
Here is the above program modified:

Code: Select all  Expand view

#include "fivewin.ch"
#include "adodef.ch"

function Main()

   local oCn, oRs
   local cVal, cRead

   cVal     := "Zürich"
   ? Asc( SubStr( cVal, 2, 1 ) )

   oCn   := FW_OpenAdoConnection( "c:\fwh\samples\xbrtest.mdb" )

   oRs   := FW_OpenRecordSet( oCn, "CUSTOMER" )
   if MsgYesNo( "Write?" )
#ifdef __XHARBOUR__
      oRs:Fields( "City" ):Value    := cVal
#else
      oRs:Fields( "City" ):Value    := AnsiToOem( cVal )
#endif
      oRs:Update()
   endif
   oRs:Close()
   oRs   := FW_OpenRecordSet( oCn, "CUSTOMER" )
#ifdef __XHARBOUR__
   cRead := oRs:Fields( "City" ):Value
#else
   cRead := OemToAnsi( oRs:Fields( "City" ):Value )
#endif
   ? cRead, cRead == cVal, Asc( SubStr( cRead, 2, 1 ) )
   oRs:Close()
   oCn:Close()

return nil
 

With this modification for Harbour while writing and reading, the data is compatibe with xHarbour, MSACCESS application.
In other words, xHarbour works correctly as it is and we need to make this modification for Harbour.

This is my observation with my tests till now. I shall continue testing extensively with different words using charcters > 128 and also with MSSQL, MYSQL, ORACLE, etc.

[Franklin Demont]

Rao ,

Thanks for the explantion.

I can confirm that in mine case the mdb-file was written with harbour and read by xharbour.

Now i build the mdb-file in the aplication , which always also read the data.

Frank