SQL Collation and Codepages

ta5
Member Posts: 1,164
Hi
We have a strange behaviour and I shall be happy if somebody could shed some light on it...
The story is to convert a native db into sql 2008r2. After checking the date fields in native and backing up, the nav restore fails because of invalid characters in customer table (character š = alt+0154). When I uncheck the checkbox "validate codepage" the nav restore on sql works, but thats not we want to do.
The server and the client where the native backup was coming from and the destination sql server have the same code page settings. In the "change database" settings the collation is set to windows. When I set to sql collation (type 41) it also works, but as far as I understand the installation guide sql collation should not be taken.
I'm interested on some theory about that, especially why the change from windows collation to sql collation makes the difference. Other question is, whats best practice regarding these topics when planning a migration to sql?
Thanks in advance.
Thomas
We have a strange behaviour and I shall be happy if somebody could shed some light on it...
The story is to convert a native db into sql 2008r2. After checking the date fields in native and backing up, the nav restore fails because of invalid characters in customer table (character š = alt+0154). When I uncheck the checkbox "validate codepage" the nav restore on sql works, but thats not we want to do.
The server and the client where the native backup was coming from and the destination sql server have the same code page settings. In the "change database" settings the collation is set to windows. When I set to sql collation (type 41) it also works, but as far as I understand the installation guide sql collation should not be taken.
I'm interested on some theory about that, especially why the change from windows collation to sql collation makes the difference. Other question is, whats best practice regarding these topics when planning a migration to sql?
Thanks in advance.
Thomas
0
Answers
-
:-) once again, some czech database...
Again, main thing is that you need to use correct language for non-unicode applications on your computer when making/restoring the backup. In this case, if I am correct, Czech one...0 -
Hi Kine
Thanks for replying. Well, its a czech character, but its a swiss database, but the name of the customer seems to be czech and so this character found its way to the "search name". Does it make a different whether the value is in a normal field or in an indexed field?
Anyway, I'm still unsure about the correct solution, because setting non unicode codepage to czech, maybe there might another field in the db from another character set...
Thanks in advance for your comments.
Thomas0 -
We have set the collation now to sql sort "Western-European dictionary sort order, code page 850, case-sensitive, accent-sensitive (41)" which works ok.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions