Migration from EA15 to EA16; What do we lose?

[Nigel_Simpson]

Does anyone know what things in EA15 are no longer supported in EA16 and what manual conversion activity is required to upgrade? Specifically, I'm concerned that my existing VBScript scripts might not be supported and that the SQL queries I have created on a .eapx file might need rewriting for SQLite database. Is there anything else I might need to rewrite or change?

[Geert Bellekens]

Probably not. Sparx is pretty good in keeping their versions backwards compatible.

Geert

[wivel]

Hi

Im with Geert on this one. I haven’t run into anything yet.

Henrik

[Nigel_Simpson]

Probably not. Sparx is pretty good in keeping their versions backwards compatible.

Geert

OK, I have upgraded to EA16 and immediately many of my SQL queries (searches, fragments) do not work, as I suspected. Examples so far are 'wrong number of arguments to instr', 'no such function cstr', 'no such function mid'. Everyone should be aware that there will be possibly a lot of manual migration work after an upgrade from eapx to qea local file.

[Modesto Vega]

Are you using a proper database as the repository or have you moved/upgraded from eapx to qeapx files?

[Nigel_Simpson]

Are you using a proper database as the repository or have you moved/upgraded from eapx to qeapx files?

I moved an eapx file to a qea file. No proper database involved.

[Modesto Vega]

You are using different database engines eap/eapx is essentially an Access database and qeapx are SQL Lite. This is why your SQL statements are broken.

Sparx is good with backwards compatibility but that does not apply and has never applied to SQL queries.

[Nigel_Simpson]

You are using different database engines eap/eapx is essentially an Access database and qeapx are SQL Lite. This is why your SQL statements are broken.

Sparx is good with backwards compatibility but that does not apply and has never applied to SQL queries.

Thank you for your input. My original question asked whether the change from eapx to sqlite would require manual actions from me. I now know it does. Others may wish to know too.

[wivel]

Hi

Yep, you are right. Did some more testing and my Jet/eapx custom SQL needs to be rewritten on SQLite/Qeax models. My custom SQL in MSSQL models ported to QEAX seems to work directly without a rewrite.

Henrik

[Geert Bellekens]

Probably not. Sparx is pretty good in keeping their versions backwards compatible.

Geert

OK, I have upgraded to EA16 and immediately many of my SQL queries (searches, fragments) do not work, as I suspected. Examples so far are 'wrong number of arguments to instr', 'no such function cstr', 'no such function mid'. Everyone should be aware that there will be possibly a lot of manual migration work after an upgrade from eapx to qea local file.

Sure, but you did more then upgrade.
You use database specific syntax in a query, then moved to a different database, and you are now surprised the other database complains about your syntax.
If I move to Oracle from SQL Server, lots of my queries will stop working as well. No need to upgrade to see that.

Geert

[Nigel_Simpson]

Probably not. Sparx is pretty good in keeping their versions backwards compatible.

Geert

OK, I have upgraded to EA16 and immediately many of my SQL queries (searches, fragments) do not work, as I suspected. Examples so far are 'wrong number of arguments to instr', 'no such function cstr', 'no such function mid'. Everyone should be aware that there will be possibly a lot of manual migration work after an upgrade from eapx to qea local file.

Sure, but you did more then upgrade.
You use database specific syntax in a query, then moved to a different database, and you are now surprised the other database complains about your syntax.
If I move to Oracle from SQL Server, lots of my queries will stop working as well. No need to upgrade to see that.

Geert

No, I didn't move to a different database - the upgrade itself did that without my asking. I'm not complaining and I'm not surprised. I only asked whether there was manual work needed as a result of the upgrade, which there is.

[Modesto Vega]

Sure, but you did more then upgrade.
You use database specific syntax in a query, then moved to a different database, and you are now surprised the other database complains about your syntax.
If I move to Oracle from SQL Server, lots of my queries will stop working as well. No need to upgrade to see that.

Geert

I think you are hiding behind the semantical ambiguities of Sparxian. Technically, what Nigel and Henrik have done is a migration (to another RDBMS) and I would not expect Access SQL to work on SQL Lite or SQL server. Having said this, if Sparx Systems is calling what Nigel and Henrik did an upgrade, instead of a migration, I am afraid they are sending the wrong signal.

P.S.: I would expect to have to change all custom SQL if I were migrating, this is why I recommend to use a proper database, specifically SQL Server or PostgreSQL and stick with it.

[Geert Bellekens]

No, I didn't move to a different database - the upgrade itself did that without my asking. I'm not complaining and I'm not surprised. I only asked whether there was manual work needed as a result of the upgrade, which there is.

Wow, how did it "upgrade" automatically? I can still use my .eap(x) files without them being migrated to an SQLite.
I would be really annoyed if EA started to migrate my models to another technology without asking.

To be fair, you did ask if there was anything else besides the SQL you needed to rewrite. I responded to that question.

Geert

[Eve]

The 64 bit edition of Enterprise Architect does not support '.eapx' model files.
You can migrate this model to a compatible format now using this upgrade too. To proceed,
select a suitable format from the supported list below.

Note you existing model will not be affected  by this process and will remain available in its
current location.

That's the text on the dialog that is shown if you attempt to open an eapx file with EA 16 64 bit. (Along with additional explanatory text describing each of the formats it will offer.)

It's described as both a migrate and an upgrade, but other than that it's pretty clear about what is going on. I struggle to see any way you can describe this as "I didn't move to a different database - the upgrade itself did that without my asking."

[Nigel_Simpson]

The 64 bit edition of Enterprise Architect does not support '.eapx' model files.
You can migrate this model to a compatible format now using this upgrade too. To proceed,
select a suitable format from the supported list below.

Note you existing model will not be affected  by this process and will remain available in its
current location.

That's the text on the dialog that is shown if you attempt to open an eapx file with EA 16 64 bit. (Along with additional explanatory text describing each of the formats it will offer.)

It's described as both a migrate and an upgrade, but other than that it's pretty clear about what is going on. I struggle to see any way you can describe this as "I didn't move to a different database - the upgrade itself did that without my asking."

I only meant that I chose to upgrade to EA16 64-bit and so I had no choice but to upgrade/migrate/move/whatever to a .qea file. I'm not complaining about it, only trying to point out to others that there may be some (considerable in my case) further activity involved in the process. I don't have access to any other 'proper' database because my client won't allow it.