Upgrading to version 6 is not a straightforward upgrade but rather a new installation, and the licences are not compatible. In fact, version 5 and 6 can even coexist on the same machine, provided they are not configured to export to the same SQL database.
As a first step we recommend that you become familiar with the new version by requesting a
30 day fully working trial licence by contacting our support team at
support@axioworks.com.
With the trial licence you can try all your replications on a test database and compare the structure of the ver. 6 tables with your existing ver. 5 ones. To do that we recommend using SQL comparison tool.
You will notice that by default the structure of the SQL tables is not identical, e.g. the naming of tables and columns now use "_" rather than ":" and ".", and the types of column use more appropriate SQL types like datetime2, date, and bigint.
However, it is possible to configure SQList to produce SQL table with a structure that is backward compatible with that of version 5. Warning: there may still be some minor differences that you will have to handle on your side.
To do that, use the options available in the Global Settings tab, sections SQL Naming and export options and Backward compatibility options.
Once you have configured SQList to generate the tables structures the way you need, you will be able to migrate to SQList version 6 following these steps:
- Install SQList 6 on the production environment (you can use the same 30 day fully working trial licence from the test environment or request a new one);
- copy the file C:\ProgramData\AxioWorks\SQList\AxioWorks.SQList.ProfileDB.sdf from the test SQList machine to the production SQList machine;
- stop your current SQList ver. 5 service (we also recommend disabling the SQList service to ensure it is not restarted accidentally);
- important: Take a full backup of all your destination SQL Server databases;
- drop all SQList generated tables from all your destination SQL Server databases (including the SQList system tables with names [(SQList.<tabe_name>)]);
- open SQList Manager version 6;
- change all Database connections to the production servers (ensure that you test the connections);
- start SQList version 6;
- check the event log for any errors.
All going well, you will see the new tables being populated in the destination databases.
How to avoid disruption to your existing systems
We understand that having the structure of the tables changed from one version to another (as small as the differences may be) can be quite disrupting to existing systems that rely on those tables.
This is true with many applications. Sometimes keeping 100% backward compatibility with previous versions is simply not possible.
To avoid this kind of disruptions, we recommend that a layer of views is built on top of the tables generated by SQList and that your other LOB systems point to these views, rather than directly to the tables, to get the data they need.
This approach gives a number of advantages:
- it creates an abstraction layer between the philical tables and the LOB systems;
- it create a single point of failure, when the structure of the underlying tables changes, that is easy to manage;
- it allows the creation of aggregate views that are more logical to the LOB systems (e.g. a total sales per month or a unnormalised list of products and categories);
- it allows the creation of a very granular access control to the data by granting access to the views.
If you have any questions or need assistance with this process, do not hesitate to contact our support team at
support@axioworks.com.