This page describes product changes you must be aware of when upgrading from version 1.xx to version 2.0x of Genero BDL.
Warning: This is an incremental upgrade guide that covers only topics related to a specific version of Genero. Also check prior upgrade guides if you migrate from an earlier version.
Summary:
Some 2.0x bug fixes and new features needed modifications inside runtime system (fglrun) and front-ends (gdc, gwc). Therefore, if you upgrade the runtime system to the latest 2.0x version, we strongly recommend to upgrade your workstations with the latest front-end version 2.0x as well.
As a general rule, when upgrading to a major or minor version like 1.33 to 2.00 or 2.00 to 2.02, you must recompile all your .4gl modules and .per form files. Re-compilation is not required when upgrading to a new maintenance release like 2.00.01 to 2.00.02.
See also Installation and Setup.
The database interface of Genero BDL 2.00 was re-designed to allow dynamic loading of database drivers. The following Informix drivers and environments have been de-supported with this re-design:
If required, old Informix drivers can be re-enabled in a next Genero BDL version. However, we strongly recommend you to upgrade the Informix Client Software development Kit (CSDK) to the most recent version supported by Genero BDL (see Installation notes).
The fglmkrtm tool has been removed from the distribution. This tool was provided in previous versions to create a fglrun runner with the correct database driver. In version 2.0x, database drivers are now always loaded dynamically. Refer to Connections for more details about database driver configuration.
The fglinstall tool has been removed from the distribution. This tool was provided in previous versions to compile product message files, form files, and program modules provided in the distribution. The compiled versions of all these files are now included in the package.
In version 2.0x, you do not need to build a runner. The architecture is now based on shared libraries (or DLLs on Windows), and the database drivers are automatically loaded according to FGLPROFILE configuration parameters.
If you have C Extensions, you must re-build them as shared libraries. Refer to C Extensions for more details.
In version 1.3x, some utility functions (canvas draw* and database db_* functions) were linked automatically to the 42r program when using fglrun -l or fgllink. These functions are implemented in the fgldraw.4gl and fgldbutl.4gl modules, which were linked in the libfgl.42x library and loaded automatically at runtime by fglrun.
In version 2.0x, all utility functions are now in the libfgl4js.42x library. So, if you use the draw* or db_* utility functions, you must now add the libfgl4js.42x library explicitly when using fglrun -l or fgllink, or you can use the fgl2p tool to link .42r programs. The fgl2p tool links the program with the libfgl4js.42x library by default.
Note that starting with version 2.21, the libfgl.42x library is no longer provided.
Refer to Utility Functions for more details.
In version 2.0x, Static C Extensions must be re-written as Dynamic C Extensions.
Refer to C Extensions for more details.
In version 1.3x, you must use FGLPROFILE entries to specify Dynamic C Extensions to be loaded at runtime.
In version 2.0x, Dynamic C Extensions are automatically loaded according to IMPORT instructions. The FGLPROFILE entries are no longer used.
There is no longer a need to define the FGL_API_MAIN macro in the extension interface file.
All C data type definitions are now centralized in the fglExt.h header file, header files like Date.h, MyDecimal.h have been removed from the distribution.
Refer to C Extensions for more details.
In version 1.3x, the WANTCOLUMNSANCHORED attribute was undocumented but still supported by the language, to simplify migration from 1.20.
In version 2.0x, the WANTCOLUMNSANCHORED attribute is de-supported; you must use UNMOVABLECOLUMNS to specify that table columns cannot be moved around by the user.
In version 1.3x, the PIXELWIDTH and PIXELHEIGHT attributes were used to specify the real size of an IMAGE form item.
In version 2.0x, you must use the WIDTH and HEIGHT attributes to specify the size of an image:
In the .per form file:
01 IMAGE img1 = FORMONLY.image1, HEIGHT = 100 PIXELS, WIDTH = 100 PIXELS;The PIXELWIDTH and PIXELHEIGHT attributes are still supported by the form compiler, but are deprecated and will be removed in a future version.
Pre-fetch parameters allow an application to automatically fetch rows from the Oracle database when opening a cursor.
In version 1.3x, the default pre-fetch parameters are 50 rows and 65535 bytes for the pre-fetch buffer. Some customers experienced a huge memory usage with those default values, when using a lot of cursors: It appears that the Oracle client is allocating a buffer of pre-fetch.memory (i.e. 64 Kbytes) for each cursor.
In version 2.0x, the default is 10 rows and 0 (zero) bytes for the pre-fetch buffer (memory), meaning that memory is not included in computing the number of rows to pre-fetch.
For more details, refer to Connections.
Version 1.3x supports PostgreSQL 7.1.x, 7.2.x, 7.3.x, 7.4.x.
Version 2.0x now de-supports all PostgreSQL versions 7, but supports PostgreSQL 8 and higher.
Remark: PostgreSQL 8 is available on Windows platforms.
Version 2.0x no longer supports Adabas D 12.
In version 1.3x, the preprocessor directives start with a (#) sharp character, to be compliant with standard preprocessors (like cpp). This caused too many conflicts with standard language comments that use the same character:
01#include "myheader.4gl"02# This is a comment
In version 2.0x, the preprocessor directives start with an ampersand character (&):
01&include "myheader.4gl"02FUNCTION debug( msg )03DEFINE msg STRING04&ifdef DEBUG05DISPLAY msg06&endif07END FUNCTION
The preprocessor is now integrated in the compiler, to achieve faster compilation.
In version 1.3x, the size of the static SQL cache is defined by a FGLPROFILE entry:
dbi.sql.static.optimization.cache.size = max
This entry was provided to optimize SQL execution without touching code using a lot of static SQL statements, especially when using non-Informix databases where the execution of static SQL statements is slower than with Informix. This is useful for fast migrations, but there were a lot of side effects and unexpected errors (refer to "Connections" in 1.3x documentation for more details).
In version 2.0x, the Static SQL Cache has been removed for the reasons described above. Programs continue to run without changing the code, but if you want to optimize program execution, you must use Dynamic SQL (PREPARE + EXECUTE) as described in "SQL Programming".
Version 1.3x has an FGLPROFILE entry to specify the database schema at runtime:
dbi.database.dbname.schema = "schema-name"
This entry could be used to select the native database schema after connecting to the server, for Oracle and Db2 only.
In version 2.0x, this entry is now specific to the Oracle and Db2 database driver configuration parameters:
dbi.database.dbname.ora.schema = "schema-name" dbi.database.dbname.db2.schema = "schema-name"
For other database servers, this configuration parameter is not defined.
For more details, refer to Connections.
Unique tool
Version 1.3x provides two schema extractors: fglschema and fgldbsch. The first can only extract schemas from Informix databases, while the second one can extract schemas from all supported databases.
In version 2.0x, the fgldbsch tool has been extended to support the old fglschema options, and fglschema has been replaced by a simple script calling fgldbsch. When you call fglschema, you actually call fgldbsch. We recommend that you use fgldbsch with its specific options.
System tables
In 2.0x, fgldbsch does not extract system tables by default. You must specify the -st option to get the system tables description in the schema files.
Remote synonyms
The original fglschema tool was searching for remote synonyms with Informix databases. The fgldbsch tool of 2.0x does not search for remote synonyms.
Public and private synonyms
Since bug fix #5021 (build 620.313), fgldbsch does not extract private synonyms anymore. Only public synonyms are extracted. The .sch schema files do not contain table owners, and if two private synonyms have the same names, there is no way to distinguish them in the schema files. Therefore, to avoid any mistakes, private synonyms are not extracted anymore.
See also: Database Schema.
An important compiler bug has been fixed in 2.0x. This bug is referenced as #5752: When you declare a module variable with the same name as a global variable, a compilation error must be thrown.
This is critical to avoid confusion with the variable usage:
01GLOBALS02DEFINE level INTEGER03END GLOBALS
01GLOBALS "globals.4gl"02DEFINE level INTEGER03FUNCTION func1()04LET level = 123 -- is this the global or the module variable?05END FUNCTION
In version 1.3x, the compiler did not detect this and the module variable was used, but one might want to use the global variable instead!
If you have module variables defined with the same name as global variables, the compiler now raises the following error:
-4319: The symbol 'variable-name' has been defined more than once.
You can easily fix this by renaming the module variable. There is no risk to do this modification, since the module variable was used in 1.3x, not the global variable.
Remark: The compiler now also detects duplicate global variable declaration. Just remove the duplicated lines in your source.
In version 1.3x, the dbi.database.* connection parameters defined in FGLPROFILE are ignored by the Informix drivers.
In version 2.0x, the dbi.database.* connection parameters defined in FGLPROFILE are used by the Informix driver, as well as other database vendor drivers. For example, if you connect to the database "stores", and you have the following entries defined, the driver tries to connect as "user1" with password "alpha":
dbi.database.stores.username = "user1" dbi.database.stores.password = "alpha"
You typically get SQL errors -387 or -329 when the wrong database login or the wrong database name is used.
For more details, refer to Connections.
In version 2.0x, Microsoft SQL Server 7 is no longer supported. Microsoft support of this version ended the first of January 2006.
Only SQL Server 2000 and 2005 are supported by Genero 2.0x. You must upgrade your server to one of these versions of SQL Server.
In version 1.3x, you could use an OPEN USING instruction to specify the SQL parameters of a following FOREACH:
01PREPARE st1 FROM "SELECT * FROM tab WHERE col>?"02DECLARE cu1 CURSOR FOR st103OPEN cu1 USING var04FOREACH cu1 INTO rec.*05DISPLAY rec.*06END FOREACH
In this case, the FOREACH instruction was reusing the parameters provided in the last OPEN instruction. Supporting such a feature is complex and deters the proper improvement of the database interface and database drivers. It was provided to support compatibility with very old Informix 4GL compilers, but it is not proper SQL programming.
The database interface of version 2.00 has been rewritten for better performance. The above usage of FOREACH is no longer supported.
To work around this issue, you can safely remove the OPEN instruction and put the USING clause in the FOREACH instruction:
01PREPARE st1 FROM "SELECT * FROM tab WHERE col>?"02DECLARE cu1 CURSOR FOR st103FOREACH cu1 USING var INTO rec.*04DISPLAY rec.*05END FOREACH
This limitation has been removed in Genero BDL version 2.11.11 (bug #12002).
In version 1.3x, it was possible to execute a prepared statement with the variable list changing at each EXECUTE statement:
01DEFINE var1 DECIMAL(6,2)02DEFINE var2 CHAR(10)03DEFINE var3 DATE04PREPARE st1 FROM "INSERT INTO tab1 VALUES ( ?. ?, ? )"05EXECUTE st1 USING var1, var2, var306EXECUTE st1 USING var2, var3, var1 -- different order = different data types
The database interface of version 2.0x has been rewritten for better performance. Having data types changing at each execute is no longer supported.
Error -254 will be raised if different data types are used in subsequent EXECUTE statements (with the same statement name).
Genero BDL version 1.33 has included an ESQL/C preprocessor named FESQLC. This component provides both SQL support and C API functions to manipulate complex types as dec_t.
Because of runtime system architecture changes, the FESQLC preprocessor could not be shipped with 2.00. However, version 2.01 provides again the FESQLC tool. Note also that version 2.00 implements Informix specific C API functions, to deploy your application without the Informix client software. For more details about the supported C API functions, have a look at the C Extensions page.
In version 1.3x, RUN...IN FORM MODE was recommended to run interactive applications.
In version 2.0x, RUN ... IN LINE MODE is recommended to run interactive applications. The RUN command should be used as follows (in both GUI and TUI mode):
For more details about the RUN options, see the RUN instruction.
In version 1.3x, only some field types like EDIT or TEXTEDIT could support TTY attributes (COLOR, REVERSE), and the conditional COLOR WHERE attribute.
In version 2.0x, all type of fields now allow TTY attributes and the conditional COLOR WHERE attribute. So when using any ATTRIBUTE(<tty-attribute>) in programs, all fields will now be affected. For example, CHECKBOX and RADIOGROUP fields will now get a colored background, while in 1.3x it was not the case.
Starting with version 2.02.01, the form compiler automatically adds HBox and VBox containers with splitter around stretchable form elements that are placed side-by-side. Thus, when recompiling your forms with this new version of fglform, the generated .42f can get additional HBox/VBox nodes even if you did not touch the .per source file.
For more details, see Automatic Horizontal and Vertical Boxes in the Form Rendering page.