Numbering Conflict when migrating to SQL

afarr

When migrating from native to SQL, part of the migration toolkit is the Code Field Information form (104013).
On my client database, this shows several columns with “Numbering conflict” = Yes.
The documentation says that sorting may be incorrect on these columns.

For some specific columns, such as “G/L Account”.”No.”:

any totals based on the field may be inconsistent. When possible, this situation can be corrected either by changing the data, or by changing the SQL Data Type property for these fields to Integer.

Some of these fields cannot be changed to integer, as they contain non-numeric data.
In any case, changing them to integers would mean that they are not standard Navision, so I’m worried of possible problems in future upgrades or fixes.
That leaves the option of changing the data. What data changes are needed – padding with 0’s on the left? How should non-numeric data be treated?

I have searched online, and in the documentation, but found no answers to these questions, which is why I’m asking here.

Many thanks in advance.

David_Singleton

Alistair you need to work this out with your partner. If you have issues such as some numeric and some alfa numeric in GL there must have been reasons for it (since this is not very common), and you need them to sit with you and work out why the data is as it is. Simply changing the numbers may make the process work,m but may not work for your business.

afarr

Thanks David.
I will look into the non-numeric data and how it came to be there. Many fields have “Compatible Integer” = Yes, so I’m guessing that the non-numeric data may be just spaces.
For the fields with numeric data, would left-padding with 0’s be enough?

Apart from the specific fields mentioned in the documentation (which might lead to inconsistent sums), there are some 200 or more fields with "Numbering Conflict" = Yes. Is this normal? Many of them are fields like "Vendor Shipment No." or "External Document No.", where it seems normal to have a mix of alpha-numeric data of varying lengths, so I don't think we'll change the data in those fields.

David_Singleton

My answer was in reference to GL Account. Each table is different and needs to be resolved knowing the data in your system and the way you do business. Most of the tables it wont matter, but some (such as GL Account) are important.

afarr

Thanks David. I will pad the G/L Account No. field to 4 characters, and review the other fields with the client.