Skip to content

Working with DataFlex 2021

Working with DataFlex 2021 is straightforward once you understand how it differs from prior releases. We recommend a step-by-step approach as you gain familiarity.

Step 1 — Install DataFlex 2021

You can safely install DataFlex 2021 side-by-side with previous revisions. The Studio is mainly a 64-bit product and defaults to the Program Files folder instead of Program Files (x86).

DataFlex 2021 installs with an extendable, 60-day evaluation license; there is no need to install a registration code to start.

Notes and recommendations: - DataFlex 2021 uses the same Codejock component revisions (18.3.0) as DataFlex 19.1. If you uninstall either product as the last action on a system, you will need to manually register those components for the remaining installation to function. Use the RegisterCodejockControls batch file in the Bin folder (run as Administrator). - If you update from a prior pre-release build, we recommend this procedure: - Stop the DataFlex 2021 Web Application Server (using the Administrator). - Uninstall the existing pre-release build. - Remove any leftover files if necessary. - Install DataFlex 2021.

Step 2 — Read the Entire What's New Documentation

Review the documentation completely — this will make your experience with DataFlex 2021 much smoother.

Step 3 — Use the Studio

If you are already familiar with DataFlex 19.1, you’ll find many similarities. If you are upgrading from earlier revisions there will be more to learn. Pay attention to these areas:

  • The Studio is 64-bit, but you can compile and debug both 64-bit and 32-bit applications. This is controlled per-project in a workspace via the toolbar drop-down. You can also set the default target in the Compiler tab of Project Properties.

  • In Project Properties you can set optional suffixes for compiled output. Our recommendation:
  • Leave the 32-bit suffix blank.
  • Use 64 for the 64-bit suffix.

  • Do not set any suffix for web applications (WebApp.exe).

  • Source file encoding:

  • Once DataFlex source is modified with the Studio it is saved as UTF-8 with a Byte Order Mark (BOM). This is different from prior OEM-based behavior.

  • Review the documentation on Unicode and encoding:

  • If you need to maintain backwards compatibility and are not immediately using Unicode, the Studio has a "Save source files as OEM" option (Configure Studio | Editor). When selected:

  • The Studio saves source files as OEM unless it detects non-OEM characters.
  • If non-OEM characters are detected, the Studio offers to convert the file to UTF-8 before saving to avoid lossy conversion.

File handling rules in the Studio:

  • DataFlex source
  • Applies to all default extensions plus any additional extensions added in Studio configuration.
  • Default mode: all files are treated as UTF-8 and saved with BOM. (During migration we do not add a BOM, so files remain OEM on disk until edited and saved.)

  • Save-as-OEM mode: files without a BOM are treated as OEM until the first Unicode character is used; then a BOM is added and the file becomes UTF-8. Files that already have a BOM remain UTF-8.

  • Other files

  • Files are assumed to be UTF-8 (prior releases assumed OEM) unless a UTF-16LE BOM is detected, in which case the file is read as UTF-16.
  • Files are always saved as UTF-8.
  • Files that already have a BOM keep that BOM. Files without a BOM stay without a BOM.

Step 4 — Experiment with the Examples

The example workspaces support compilation in both 64- and 32-bit and support Unicode (you need a Unicode-capable database such as SQL Server to store Unicode data). The Order Entry examples (Web or Windows) are a good place to start.

Example steps using the standard Order Entry Windows workspace:

  • Open the Order Entry workspace in the Studio.
  • The project is set to compile for 64-bit and compiler warnings are enabled.
  • You can toggle between 64- and 32-bit and run/debug both from the 64-bit Studio.
  • Open the Customer view and translate text using Google Translate. Example translations:
  • "Customer Entry View" → "Приказ на влез на клиент" (Macedonian)
  • "Customer Number:" → "Број на клиенти:"
  • "Street Address:" → "街道地址:" (traditional Chinese — demonstrating mixed languages)
  • Make changes and compile and run.
  • You can use the Studio editor, object properties, wizards, etc. to add Unicode text.
  • Compile and run (either 64- or 32-bit) and observe the UI.

  • The embedded database is OEM-only. If you enter Unicode data (for example change the "Access Miles" customer name to Chinese "訪問里程") and save:
  • The UI controls support Unicode and will display the characters.

  • Saving to the embedded database will result in loss (characters turning into "???") because the embedded database is limited to OEM.

  • To use Unicode data persistently, convert the Order Entry database to Microsoft SQL Server:

  • Create a Managed Connection and an Order Entry database.
  • Use the SQL Conversion Wizard to convert table structures and data to SQL Server.
  • DataFlex ASCII columns will be converted to nvarchar columns, which support Unicode (where varchar would not).

  • Compile and run again and you can use Unicode data throughout the application.

The same basic steps apply to WebApps.

DataFlex 2021 also includes drivers for IBM DB2, MySQL, PostgreSQL, MariaDB and Oracle. Relevant setup guides: - How to set up and test using Aurora - How to set up and test using IBM DB2 - How to set up and test using MySQL - How to set up and test using PostgreSQL - How to set up and test using MariaDB - How to set up and test using Oracle

Step 5 — Migrate Your Applications

Migrating your own applications is the most interesting part. The migration steps depend on your starting point and goals. Consider the following before you begin:

Migration stages - Basic migration: make only the changes necessary to compile and run under DataFlex 2021. The application may still be 32-bit and not use Unicode capabilities. This may be appropriate if: - The application uses the embedded database (OEM). - You use third-party components without 64-bit/Unicode-capable versions. - You do not need 64-bit or Unicode capabilities but want the updated development environment. - Subsequent stages: - Address Unicode-related compiler warnings. - Convert to full 64-bit. - Convert data to a Unicode-capable database (for example, Microsoft SQL Server).

Example migration workflow (DataBase Builder project used as illustration): - Make copies of your application and library workspaces for DataFlex 2021. - Ensure references point to the copied libraries. - If using an SQL back-end, copy databases and verify no SQL data still uses the OEM Table Character Format. - Update managed connections to use the new databases. - Verify the copied structure and data compile and run in their original host revision. - Open the workspace in DataFlex 2021 Studio and migrate libraries and workspaces in place (simplest for experimentation). - Migration changes depend on the host revision; migrating from 19.1 typically changes the revision in the .sws file and adds lines to .cfg files. - Migrated projects are initially set to 32-bit and compiler warnings may be suppressed. - Compile and inspect errors/warnings. - If not previously migrated to 19.1, many errors will be due to code cleanup changes in that revision. Add OldDFAllEnt.pkg and/or OldFMACCommands.pkg to check for those errors and recompile. - You may see many warnings when enabling compiler warnings; the process is iterative.

Practical tips: - Prune unused old packages (for example copy OldDFAllEnt.pkg to AppSrc and remove unused Use statements). - To focus on Unicode-related issues, add these lines to your application (after Use DFAllEnt.pkg for Windows or Use AllWebAppClasses.pkg for WebApps):

CompilerLevelWarning General Off
CompilerLevelWarning Unicode On
  • This will show only Unicode-related warnings and help prioritize changes.
  • If using the embedded database, convert your data to SQL Server using Managed Connections and the SQL Conversion Wizard. Check that ASCII columns you want to be Unicode are converted to nchar/nvarchar.
  • If you already use SQL Server:
  • Determine whether you originally converted data using ANSI or OEM conversion. If OEM, use the OEM to ANSI Conversion Wizard for updates.
  • Change ASCII column data types to nchar/nvarchar for columns that should store Unicode. Existing ASCII data will not be lossy when changing column types.

High-level migration checklist: - Determine the target migration stage for each project. - Understand the types of changes required. - Use Studio errors and warnings to find code that needs changing. - Review external components and APIs and update as needed.

Migration is repetitive — you will encounter similar types of changes many times. The key is learning how to handle each change type efficiently.

Step 6 — Use the Forums and Learning Center

Use the community resources: - Windows Applications forum: https://support.dataaccess.com/Forums/forumdisplay.php?26-Windows-Applications - Web & Mobile forum: https://support.dataaccess.com/Forums/forumdisplay.php?6-Web-amp-Mobile-Applications - Database Connectivity forum: https://support.dataaccess.com/Forums/forumdisplay.php?20-Database-Connectivity - Reports forum: https://support.dataaccess.com/Forums/forumdisplay.php?31-Reports - DataFlex Learning Center: https://learning.dataaccess.com/

Participating in forum discussions can save significant time and sharing your experiences helps other developers.

Step 7 — No Excuses

Take the time to read the documentation — it won’t take long, and it will save you time later.

See Also