Different Collation per. Company – anyone tried it?

pdj
Member Posts: 643
(NAV 2009 Classic.)
We are having issues with a database that is going to be used from several countries around the globe – both Europe and Asia. Each country has their own Terminal Server set in local non-unicode codepage. Each company is only used in one country, but we are unable to store local chars unless the collation of the database match the language of the country.
We are therefore considering batch job that changes the collation of all Text fields in the tables belonging to each company. (we are also considering Code fields, but we don’t think it will be necessary) We foresee a few issues , but nothing serious:
Has anyone tried this approach or have any objections or recommendation about it?
We are having issues with a database that is going to be used from several countries around the globe – both Europe and Asia. Each country has their own Terminal Server set in local non-unicode codepage. Each company is only used in one country, but we are unable to store local chars unless the collation of the database match the language of the country.
We are therefore considering batch job that changes the collation of all Text fields in the tables belonging to each company. (we are also considering Code fields, but we don’t think it will be necessary) We foresee a few issues , but nothing serious:
-
Not handling shared tables
Might cause issues if we access the SQL tables directly for JOINs or replication etc.
We need to run the batch job each time a FOB is imported.
Does not allow object names or fields names to be localized
Has anyone tried this approach or have any objections or recommendation about it?
Regards
Peter
Peter
0
Comments
-
Have you taken into account possibility like upgrade to NAV 2013 with the Unicode support? Of course, I know that it could cost you big money if you have too much customized database, but I want to know if you have though about that... because I will never go the way you are trying to go...0
-
Yes, we know the problem will be solved in the new NAV versions supporting Unicode.
However; the customer is currently using multiple different customized NAV databases, and one of the first steps is to merge all these databases into one before we expect to upgrade them to NAV2015 or NAV2015R2 at a later point.
I must also admit I didn't like this approach in the beginning, but after having thought about it, I doubt it will cause any major problems.
That's why I would like to know which issues you expect or fear we might encounter?Regards
Peter0 -
What about tables which are DataPerCompany=No? Like users (some countries have local characters in windows logins), roles and permissions...0
-
Yes, that was what I meant with "Shared tables", which we don't expect to be a problem keeping with English chars.
We just need to be able to name masterdata like G/L Accounts and Customers and Vendors and Items and Sales People etc. with national chars.Regards
Peter0 -
Just found a tool claiming to solve the problem:
http://www.octocon.de/index.php?article_id=12&clang=1
Anyone tried that, or know how it solves the problem?Regards
Peter0
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