I’m in the process of migrating from C/SIDE to SQL, during testing (migrate.fob) I have received a number of code field issues that will occur when I migrate, such as the known sorting sequence difference between C/SIDE and SQL. These particular code fields hold both alphaumeric and integer values, I was considering making use of the SQL Data Type ‘Variant’ which is a property within each field which sorts the data into alphanumeric then integer. Does anyone know any side effects of using the Variant SQL Data Type? Thanks Michael
You need to make a decision based on the particular business of your company. The sorting may not be an issue for you, in which case you don’t need to change anythign, ont he other hand it may be inmportant. The most significant case is where you have reporting or calculations based on a range of records, and that the new sorting wll effect those reports or totals. Say for example you have items: 001 001-D 011 01123 01123-B 01123-C And you have areport that sets on a range of these items, and generates (say) sales totals, then the report simply wont work anymore. But sorry there is no generic answer to the question. Speak with your NSC, they will have done the development wortk that will be affected, and should know your business requirements.
hi
my client is using Navision 3.7 and he want to migrate his c/side to SQL server so can u suggest me which version of SQl is advisable 2000 (or) 2005 considering the compatibility of the NAVISION 3.7 Application
If you remain on v3.7, then SQL2000 should be your choice.
SQL2005 (and later) oficially are not supported for NAV 3.7 - though tehnically it is possible, sooner or later problems will arise.
The sql_variant datatype should be the last desperate choice right before you turn up your toes and die!
In filters, it forces SQL Server to inplicitly convert data types, and this usually prevents index usage. So better NOT.