We have some tables that use BIGINT. Servoy has no problem with this until it comes to exporting the solution and importing the solution to a new database (both export and import = MSSQL). Although the exportfile.servoy seems to have defined these fields as INTEGER, the created field has become a NUMBER (on db level a double).
A second import on the same database notices these differences and gives a warning that the target differs from the source.
Anyone any experience with this?
Jos,
When you create a column in Servoy developer, the column will be created in the db using the specific dialect.
The actual type reported by the driver is stored as column type.
A new import that wants to create the column will use this last column type icw the then used dialect.
For Servoy 6.1 we are planning to change this so that the original requested type is used, not the type reported from the development db.
As a workaround you can create the column or table yourself in the db using your db tools, Servoy will work with the existing table.
Rob
Hmmm by a ‘dialect’ you mean the kind of database I presume (MSSQL, Postgres, MySQL etc.) ?
This is not my problem. I used for the above experiment only MSSQL.
The problem is that I need a BIGINT instead of a regular INTEGER as defined in Servoy. So I created a column in Servoy and defined it as an INTEGER. Then I altered this column with database tools to a BIGINT. Still in Servoy this column is treated as INTEGER, which is allright.
Then I do an export of the solution and import it somewhere else, for instance an application server. I need to rebuild the database in the new environment, and I see that Servoy has altered my BIGINT column to a NUMBER. When I import the same solution a second time, I get a warning that there is a difference in import and export: a column is described as INETEGER in the importfile but already exists as NUMBER in the database. Ergo: the exportfile contains the right description.
Of course I can alter the database with db tools but when I have to update more than 100 clients with a new solution and I see that the database changes made by Servoy are not correct this is somewhat annoying.
Jos,
This is inherent to the difference between column types in sql and java.
Servoy has the java type, when the column is to be created this is done via a db-specfic (dialect) mapping from java type to sql type.
Next, Servoy asks the db driver the actual (java) type, unfortunately this is not always the same type as the original one.
If you want full control over your column types, best to create the data model with db-specific tools.
Rob