2 min read

Custom OEM to ANSI Translation

Mertech's drivers have a standard OEM to translation based on the Windows API. When this feature is enabled, data sent to the SQL database is translated from the OEM to ANSI Character set and from ANSI to OEM before the data is sent back to the application.


The new version 11 drivers have a new feature available that allows the user to customize the mapping value for the OEM to ANSI translation. Basically the user can customize the OEM and the ANSI Character Translation using a macro command or through the mertech.ini file entry. The difference between these two approaches it is that the macro command must be added to each application, which means that some code has to be added and then the application source code has to be recompiled. But on the other hand, the use of the mertech.ini introduces the use of the Custom OEM to ANSI Character Translation automatically when the INI file is read during the driver initialization.

 

Using a macro command we can customize the OEM to ANSI Character Translation calling:

SET_CUSTOM_OEM_TO_ANSI CharEntry To OEM OEMValue ANSI ANSIValue

where

CharEntry It is the character entry position (0 to 255)
OEMValue  It is the character number for the OEM character
ANSIValue It is the character number for the ANSI character


For example, we want to change the OEM to ANSI Character Translation for the characters 128 and 135 and set it to be translate to the blank space (' ') :

SET_CUSTOM_OEM_TO_ANSI 128 To OEM 32 ANSI 32
SET_CUSTOM_OEM_TO_ANSI 135 To OEM 32 ANSI 32


If you need to use a custom OEM to ANSI translation, you do have to customize the needed values before you read or write any data from a SQL Table. This means that if you save some data using the standard OEM to ANSI translation (or even if you don't use any OEM to ANSI Character Translation) you will end up getting unexpected character values instead. So pay attention when using it.


There is a macro command you can use to get the current OEM to ANSI character translation settings. You do that by calling:

GET_CUSTOM_OEM_TO_ANSI CharEntry To OEM OEMValue ANSI ANSIValue

where

CharEntry It is the character entry position (0 to 255)
OEMValue  It is a variable to keep the value  for the OEM character
ANSIValue It is a variable to keep the value for the ANSI character


For example, we want to get the current values for OEM to ANSI Character Transation for the characters 128 and 135:

use mertech.inc
Integer iOEM128  iANSI128
SET_CUSTOM_OEM_TO_ANSI 128 To OEM iOEM128 ANSI iANSI128
Integer iOEM132 iANSI132
SET_CUSTOM_OEM_TO_ANSI 135 To OEM iOEM132 ANSI iANSI132


If you want to use the mertech.ini file to set up the Custom OEM to ANSI Character Translation, then you will have to add an entry for each character, using the CustomOEMToANSI  token followed by 3 numbers between comma, like:

CustomOEMToANSI   CharEntry, OEMValue , ANSIValue

where

CharEntry It is the character entry position (0 to 255)
OEMValue  It is the character number for the OEM character
ANSIValue It is the character number for the ANSI character


For example, the following mertech.ini file has the token entry to customize the OEM to ANSI translation for the characters 150, 151, 152 for SQLFlex and PgFlex drivers:

[MSSQL]
CustomOEMToANSI   150, 85,117
CustomOEMToANSI   151, 115,118
CustomOEMToANSI   152, 125,113

 [PGSQL]
CustomOEMToANSI   150, 85,117
CustomOEMToANSI   151, 115,118
CustomOEMToANSI   152, 125,113


You can see that we need to add an entry with the 3 pairs of numbers for each character we want to customize.


If you want to make the Custom OEM to ANSI Character translation to take place since the DataFlex data file migration, then you will have to use the mertech.ini file approach. Before you can use Flex2SQL migration tool, you have to set up your mertech.ini file first.

 

 

Why Migrate from Btrieve to PostgreSQL and other Relational Databases?

Why Migrate from Btrieve to PostgreSQL and other Relational Databases?

Introduction Many independent software vendors (ISV) and corporate users still rely on applications that use a category of database collective called...

Read More
Four Challenges in Converting COBOL Applications from ISAM Databases to Relational Databases

Four Challenges in Converting COBOL Applications from ISAM Databases to Relational Databases

COBOL applications are the foundation of numerous essential business functions, especially within the banking, insurance, and government sectors....

Read More
Application Modernization 101: Ultimate Guide to Digital Transformation

Application Modernization 101: Ultimate Guide to Digital Transformation

Imagine breaking free from the constraints of old, monolithic systems and embracing the agility and innovation of cloud-based solutions.

Read More