SetAnsi(false) not needed in X# with ADS?

[ic2]

Frank works on an X# conversion and once he pastes an ANSI character in an SLE in a converted VO form, the character shows incorrect, unlike in VO. E.g.:

straße changes into straáe.

Once he runs SetAnsi(true) the problem is solved. However, we all use ADS which requires SetAnsi(false) to prevent both VO and ADS to convert OEM to ANSI.

Is my conclusion correct that this SetAnsi(false) is not required in X#, contrary to in VO (and that a false setting influences all kind of string manipulations, besided the mentioned sle paste e.g. a function building ansi characters also gave different results compared to in VO, in their program)

Dick

[ic2]

Robert, Chris, can you confirm this?

Dick

[Chris]

HI DIck,

Yes, indeed SetAnsi(FALSE) affects several things and normally is not needed in X#, unless you need to share dbfs with old programs written in Clipper etc. Are you sure ADS requires SetAnsi(FALSE)?

[wriedmann]

Hi Chris,
in VO SetAnsi( false ) is needed for ADS to stop conversions.
The ADS help says:
"In order for the Advantage RDD to work properly, the SetAnsi value must be False. The Advantage RDD takes care of all conversion and always returns the data in the native Windows format-ANSI. If you incorrectly set SetAnsi() to True in your Advantage application, Visual Objects will incorrectly assume the data from the Advantage RDD is not ANSI and will also perform conversion, which will corrupt your data. The Advantage Visual Objects RDD will use the SetCollation() value to determine if ANSI conversion is necessary as explained below."
Wolfgang

[ic2]

Thanks Chris, Wolfgang, to add: the 'explanation below' from the ADS help as Wolfgang posted is:

"If the data is stored in the DBF as OEM data (to be shared with a Clipper application for example), it must also be collated using the Clipper collation sequence (which is ASCII for the English language). Therefore, add the line SetCollation( #Clipper ) to the beginning of the application (before any data files are opened). Since the data is stored as OEM characters, the data will be translated automatically by the RDD to ANSI for use with Visual Objects (because all Windows applications require data to be represented in the ANSI character set).

If the data is stored as ANSI characters, the RDD will need to collate the data using ANSI collation sequences. The data cannot be shared with DOS applications such as Clipper Therefore, add the line SetCollation( #Windows ) to your application before any data files are opened (this is the default). The RDD will read and write ANSI characters and no conversion will take place."

I can enter a >128 ANSI character in the VO version (ADS, SetAnsi(false)) which shows correctly in the X# version of the program (SetAnsi is not set and then it appears to be true) where I can do the same, the other way around.

Despite knowing the help text I am still not sure why it works correctly in VO with SetAnsi(false) -implying dbf is native Windows ANSI format and need no conversion, and SetAnsi(true) in X# (required to paste correct values in SLE's). But why isn't ADS here "incorrectly assuming the data from the Advantage RDD is not ANSI and will also perform conversion" as the help file says about VO?

(I mix the use of both; there are a few advantages in the X# version but not everything is yet converted)


Dick

[wriedmann]

Hi Dick,
do you have ever tried to put a euro character in an ADS database field? At least with VO I was never able to do that....
Wolfgang

[robert]

Guys,
ADS does the indexing on the server. So the collation is not really relevant, however the RDD asks the runtime for the current collation and derives the charset parameter for AdsOpenTable90() from the collation. Collation Clipper = ADS_OEM, Collation Windows is ADS_ANSI.
It does the same for the char parameter in AdsCreateTable90()
I do not see (in the Vulcan RDD) what ADS does with the SetAnsi() setting.
For VO I do not know this.

Robert

[ic2]

Hi Dick,
do you have ever tried to put a euro character in an ADS database field? At least with VO I was never able to do that....
Wolfgang

Certainly, no problem. I can add it in a VO or a (Winforms) X# SLE, save it and it stores in the (ADS driven) DBF like any other >CHR(128) character.

Here's how it looks like in my DBV utility (again: all is opened under ADS):

euroindbf.jpg (7.17 KiB) Viewed 60 times

I wonder why you can't while the ß is no problem?

I also understand from the reply from Robert that it is a bit a black box how the RDD's and ADS work. So I have to rely on what seems to work: SetAnsi(false) in VO as that is required according to the ADS help and no SetAnsi setting (apparently meaning that it's true) in the X# program. Then I have to make sure that the DBF's themselves are ANSI (you can see that in dbMax, Database and RDD info, and also export a DBF as OEM or ANSI there) and then we open all our dbf's in ADS and then it seems to work fine as far as I can see, mixing the use of an X# and VO version of the same program.

Dick