Basically, the conversion process opens each object in each model (including Backup models if available), checks it for errors, and saves it again adding certain information. See
KB Conversion Process for more information.
In certain situations, the original Knowledge Base has problems that hadn't been detected because the object hadn't been saved and/or specified with more recent
GeneXus versions.
It's important to remember that the KB is always converted. That is to say, those objects that don't have problems are converted. The objects that have errors aren't saved in the 9.0 version, they are left just as they were before the conversion process.
To solve these problems, you need to examine each case separately.
You can read more information about how errors are reported and how to obtain a list of them at:
KB Conversion Process
The recommended strategy for solving potential conversion errors is as follows:
1. Keep the XML file containing the problem log, whether it is your own or the ConvertTo90Log .gxl
2. For every problem, open the corresponding object in the older
GeneXus version that you had been using so far and try to save it. In this way, you'll see whether the problem is pre-existent or conversion-related.
NOTE: Remember that every error includes the object and model where it occurs. It's important that you try to save the object in the model mentioned in the log because the same object may not give an error in another model.
The actions to take depend on the results of this procedure.
Below is a list of problems detected by the conversion tests and their possible solutions.
Problem:
This is the case of variables whose name starts with a number.
Since version 8.0,
GeneXus doesn't support variables whose name starts with a number. If you try to define such a variable, the message "Invalid first character." is displayed. (
more info)
Solution:
Open the object that has this type of variable and rename it.
Problem:
In DOS versions of
GeneXus , it was possible to define the Noconfirm() rule without passing a parameter -an attribute that indicates the level.
In
GeneXus for Windows this became a property (Confirmation) and for compatibility reasons the Noconfirm() was still supported, as long as the corresponding parameter was included.
Solution:
Open the object that has this rule, add the parameter (attribute that indicates the level) and save it.
Problem:
If, when defining a variable, its name matches an attribute name, it inherits the attribute properties such as type, length, etc.
There may be a variable whose name matches that of an attribute, but that they are of different type. Also, the attribute may have a value range.
The error occurs if these conditions are met and this variable wasn't defined in the definition dialog because it was created in versions older than 8.0.
Solution:
Open the object with this variable, change its definition, and save it. Restore it to the original definition and save it.
The objective of this process is to prevent it from inheriting the value range.
Problem:
The problem may be that there's an object with more than one parm rule for the same environment (win, web or bussiness). This was allowed in previous
GeneXus versions, even though it was wrong.
Solution:
It makes no sense to have more than one parm rule for the same environment. So, edit the object, remove the incorrect rule and save the object.
NOTE:
Using B2 the error was "Internal Error in Function Save Parameter Name: -1 (ISAM Error 0-46-17-0) {}". The solution using this Beta was to define the correct parm rule and delete the other one, using the original
GeneXus version.
(The ISAM and the message may vary but it is esentially the same problem.)
Problem:
The first message appears if the parm rule has an attribute that doesn't belong to any table.
The second one appears if this attribute is present in another part of the object.
If you list this attribute, the following message is displayed. "Warning: attribute is not in any table."
Solution:
Depending on each case, it may be an attribute that needs to be included in a table, or that it shouldn't be in the parm rule or other parts of the object.
Therefore, this problem needs to be solved on a case-by-case basis.
Problem:
The problem could be a model using Pocket PC Generator (Embedded VB) is being converted
Solution:
The Pocket PC Generator is not longer support (from 9.0 or higher versions).
.NET Mobile Generator (GX 9.0) generator should be used.
Problem:
The conversion process assumes that undefined variables used in the Parm() rule are Numeric(10,2) or, if they have the same name as an attribute, it uses the attribute definition. It does not analyze the source code to find the first assignment to the undefined variable.
If you have programs with undefined variables in the Parm() rule you may experience specification time warnings and compile time errors if the actual variable definition is
not Numeric(10.2).
Solution:
Define all variables used in the Parm() rule.
In the conversion process of tens of KBs and thousands of objects we have detected some common cases and we think that documenting them here may be a contribution to those starting this conversion process.
NOTES:
Problem:
Important improvements in comboboxes definition and handling were implemented in
GeneXus 9.0 version. Among them, the combo Description Attribute is checked out to verify that it is defined as "Unique Index". In other words, if you load a Clients combo in the Clients table there should be a Unique index by ClientName. Otherwise, duplicated values may appear in the table and therefore in the combo and eventually the user will not know (if duplicated values appear) what the correct value to be selected is.
Solution:
Ignore the warning, disable it as explained above or define a unique index.
Problem:
When an object is saved (such as during the conversion), the rules, events, etc syntax is controlled.
As from 9.0 version, these controls are stricter to avoid future errors or unexpected problems.
If for some reason, there is more than one control or attribute with the same name and one of its properties is assigned or one of its methods is used, on saving the object GX is unable to determine what is it (a control, an attribute, etc.), and therefore the error occurs.
E.g.: there is an attribute "A" in a Transaction structure and there is a "textblock" called "A" in the transaction form.
The error will be: "Rules, Line 3, Col 1 : Identifier 'A' is ambiguous. It identifies an Attribute and a Control. Please rename one of them"
Solution:
Any of the controls must be renamed.
NOTES:
- In the case of multiple forms, for instance in the transactions, bear in mind that the ambiguity may occur with any of the forms you are using.
- In some cases, if the property or method used is only available for attributes or controls, the ambiguity is solved by assigning this type.
E.g.: Suppose an assignment like "A.caption="Value" is being done. As "caption" is a property only available for controls so, in case of ambiguity, "A" is considered as a control.
In this case, the message would be similar to this: "Rules, Line 5, Col 21: Identifier 'A' is ambiguous. It identifies an Attribute and a Control. Resolved as a Control."
- If you have the Functions property with value "allow non-standard functions" GeneXus is unable to solve the ambiguity as explained above; nevertheless, some cases are solved giving a similar warning. Anyway, it's recommended having this property at object level instead of at model level so that it only affects the objects using the non-standard methods, properties or functions.
The
ApplicationLocalization feature, included in GX 9.0, implies that, for each object, a cross-reference of the literals used by this object is kept.
When an object is specify, a NombredeObjeto.CLL file is created (in the directory of the user making the specification), This file contains the literal number of each literal contained in such object. After the specification process, this file information is saved in the KB.
This does not modify performance substantially since it was optimized in such a way that the new literals are added to the cross-references and the literals that will be no longer used are deleted. I.e.: they are not eliminated as a whole and included as a whole each time in the "cross-reference".
Nevertheless, if a KB has been converted, a build all of this KB is the first thing to be typically performed. At this moment, all CLLS are created and the whole messages (literals) cross-reference is updated, which may make the first build all slower.
The message displayed is "processing inferred calls".
Summary: the first build all of a KB in 9.0 version (the first thing to be typically performed) may take more time than expected since this information is being saved in the cross-reference. The following specifications will have better performance.
Comments & Collaboration
Hacer una copia de la KB a migrar
Copiar el directorio de la KB incluyendo, al menos, el sub-directorio KBData a un nuevo directorio y realizar la migración sobre esta copia. Nunca migrar la KB original.
Hacer un Rebuild -Y
Antes de hacer la migracion, hacer un rebuild -Y, para asegurarse que no hay problemas de indices corruptos en la KB.
Borrar todos los modelos no utilizados
Si bien no es necesario, para que la conversión se más rápida, antes de migrar, es recomendable borrar todos los modelos no utilizados y el modelo de backup si lo hubiera.
Borrar objetos no usados
Esta recomendacion es básica, pero muchas veces ahorra mucho trabajo, el borrar todos los objetos no utilizados, en la KB antes de migrar.
Instalar los generadores Origen y Destino de la version 9.0
Si en la migracion de la KB, se esta haciendo tambien un cambio de generador (por ejemplo de C/SQL a .NET, o de VFP a Java) se recomienda instalar tambien el generador Origen en la version 9.0, aunque el mismo luego no se vaya a utilizar. En el proceso de migracion, muchas veces es necesario archivos de propiedades del generador origen, y al no encontrarse da errores.
Conversion de la KB
Abrir la KB y hacer la conversion. Salvar el archivo de objetos que tienen errores de conversion. Este debera ser utilizado para solucionar los problemas que se reporten.
Testeo inicial antes de un build all
Elegir un objeto main sencillo, que se conecte a la base de datos, y especificarlo, generarlo y correrlo, para chequear las propiedades basicas del modelo.
Build all
Revisar cuidadosamente las propiedades del modelo, sobre todo las nuevas propiedades.
Borrar los *.ari del modelo
Hacer un build all forzado.
Anotar los errores y warnings y corregirlos.
Make a copy of the KB to be migrated
Copy the KB directory including at least the KBData Subdirectory to a new directory and perform the migration over this copy. Do never migrate the original KB.
Do Rebuild -Y
Before performing the migration, do rebuild -Y to make sure that there is no corrupted indexes problem in the KB.
Delete all unused models
This is not necessary, but to achieve a faster migration we recommend deleting all the unused models and the backup model if any.
Delete unused objects
This recommendation is elementary, but deleting all unused objects in the KB before migrating does frequently save plenty of work.
Install 9.0 version Source and Target generators
If in the KB migration you are also changing the generator (e.g.: from C/SQL to .NET, or from VFP to Java) we recommend installing also the Source generator in the 9.0 version even if it will not be used later. During the process migration, it is frequently necessary to have properties files of the source generator available and when they are not found errors occur
KB Conversion
Open the KB and perform the conversion. Save a file with the objects that have conversion errors. It will be used to solve problems reported later.
Initial Test before a build all
Select a simple main object that accesses the database and specify, generate and run it to check the model basic properties.
Build all
Check out the model properties carefully, mainly the new properties.
Delete the model *.ari.
Perform a forced build all.
Take note of the errors and warnings and correct them.