Installation

Whether you are installing for Windows or Linux, the installation program is run on a Windows machine. The Flex2SQL Setup Wizard guides you through the installation process. Follow the prompts, accepting the terms of the license agreement.

Flex2SQL Utility Install.png

The install program installs a DataFlex (DF) single user distribution license for running Flex2SQL. Regardless of the version of DataFlex you are using, Flex2SQL (which previously was compiled for all available versions of DataFlex and used the already installed DataFlex runtime components) now deploys its own runtime component. This standardization was made possible by the introduction of a DataFlex Workspace Manager that allows Flex2SQL to select and work with any version of DataFlex on Windows.

Installing for Linux

When installing for Linux, you first need to install on a Windows PC so you have access to the migration utility on Windows and the shared objects that will be needed on Linux. Select the Complete setup type option in the Flex2SQL Setup Wizard to install the Linux drivers.

Flex2SQL Utility Install.png

When the Complete option is selected, the linux subdirectory is included in the install tree directory under the <Program Files>\Mertech Data Systems\DB Drivers\DataFlex folder

The client subdirectory contains the libraries used by MySQL and PostgreSQL. The shared subdirectory contains the drivers for Oracle (ora_drv.so), MySQL (mdsmysql.so), MariaDB (f2s_md.so) and PostgreSQL (mdspgsql.so). These drivers were compiled without any of their library dependencies.

The static subdirectory contains the drivers for Oracle (ora_drv.so), MySQL (mdsmysql.so), MariaDB (f2s_md.so) and PostgreSQL (mdspgsql.so). These drivers were compiled with the basic environment libraries.

Use the ldd command to list the driver’s shared library dependencies. For example: ldd ora_drv.so. The runtime environment must provide the required libraries.

ciText for PostgreSQL

The PostgreSQL ciText module provides ciText, a locale-aware, case-insensitive Text type. Essentially, LOWER() is called when comparing ciText values. Otherwise, ciText data types behave exactly like Text.

The Mertech driver for PostgreSQL supports data type ciText to allow for case insensitive fields without the need for inverse key columns. Using the ciText SQL functions provides much better performance with case- insensitive data types than using inverse keys.

When you login in to a PostgreSQL server, the driver checks to see if the PostgreSQL server has ciText support enabled. If ciText support is not enabled a message displays to explain how-to enable this feature on your PostgreSQL server.

Flex2SQL023.png

Note

Install the ciText module by running pgsql/contrib/citext/citext.sql. For later versions of PostgreSQL you may have to run the CREATE EXTENSION citext command. Refer to PostgreSQL documentation for additional information.

Important Oracle Information

For Oracle you must have an Oracle client installed. Our Deployment Tools include an in-place OIC (Oracle Instant Client) that makes deployment easy. If you want to use your own Oracle client, make sure that the following Oracle environment variables are properly set.

  • ORACLE_HOME: The top level directory that contains the database client software or the entire database installation. The driver needs the Oracle client libraries and files that are located through this environment variable. Each user must have this environment variable properly set to use the driver.

  • TNS_ADMIN: The directory that contains the Oracle file tnsnames.ora, which allows calls to the Oracle database to set the required server connections.

If installing the Oracle driver using shared libraries, the library path environment variable must also be set. This variable lists the directories to search for dynamic-link libraries. We recommend that this variable it be placed in each user’s profile after the ORACLE_HOME environment variable is set. If the library path environment variable is not set, the driver will not function properly since it will not be able to find the Oracle libraries. Set the library path environment variable:

  • PATH: on Windows

  • LD_LIBRARY_PATH: on Linux

Oracle License Count View

Server-side control scripts must be run before you connect to Flex2SQL for Oracle. These must be run as a SYSDBA.

  1. Select the Flex2SQL Utility shortcut from the Windows Start menu.

  2. In the Server Type field, select Oracle from the drop-down list.

  3. Select SYSDBA from the AutoMode drop-down list.

  4. In the Server Name field, type the name of the server you are logging into.

  5. In the User Name field, type the SYSDBA user name (for example SYS or SYSTEM).

  6. In the Password field, type the user password.

  7. Click Connect to log into the server. Server-side license scripts run automatically.

  8. Logout then login as a DEFAULT user before performing any migration work.

Note

If you do not have DBA privileges, ask your DBA to run one of the following scripts to create the required Mertech view.

For a non-RAC Oracle database:

create or replace view mds_session_info as select username, machine, terminal, module from v$session where module like 'ORAFlex%';
grant select on mds_session_info to public;
drop public synonym mds_session_info;
create public synonym mds_session_info for sys.mds_session_info;
commit

For an Oracle Real Application Cluster (RAC):

create or replace view mds_session_info as select username, machine, terminal, module from gv$session where module like 'ORAFlex%';
grant select on mds_session_info to public;
drop public synonym mds_session_info;
create public synonym mds_session_info for sys.mds_session_info;
commit

Questions have been asked about the requirement to create the MDS_SESSION_INFO view within the SYS schema. The purpose of MDS_SESSION_INFO is to limit v$session information that is available to the application user to only Flex2SQL connections (“where module like ORAFlex%”).

Alternately, you can create the view in the user’s schema, but you must then add grant select on v_$session; to the script. Since v_$session is the underlying table of v$session view, this method opens up v$session to the user.

We recommend creating the view as the SYS user, since this provides the highest-level of security.