How to deal with MSSQL language portability issue in ASP.NET - Part 2

Apr 15, 2014 by Alexandra

If in Part 1 we've detailed what exactly generated a MS SQL Server language portability issue, now I'll detail the solution. I hope you didn't wait too long :)

A quick workaround

The fastest workaround for the MS SQL Server language portability issue (but still, not a perfect solution; for building a proper code, please see the "Best practices" detailed below) is to simply add the preferred language to your connection string:

<add key="MyConnectionString" value="packet size=4096;Password=pass; 
Persist Security Info=True; User ID=sa; Initial Catalog=MyDatabase; 
Data Source=.\SQL2008;Current Language=English/>


The advantages of this approach are:

* Whenever you decide to change the SQL server to one with a different language, it requires only a small change in the same area
* It does not require code alterations which can cause inconsistencies in the long run

Best practices

* When in doubt what date format to use, always go with the ISO date format! This comes in two "flavors": YYYYMMDD (no dashes) and YYYY-MM-DDTHH:MM:SS (dashes are optional) where the "T" separates the date from the time. Both these formats have been accepted since the Microsoft SQL Server 2000 version
* Use the English version of Microsoft SQL Server, since it is widely accepted
* I would recommend to always choose English as the database language. If this is not possible, then keep in mind that:

   - English is the most widely used language in the world, especially in IT. It can be considered the lingua franca of programming.
   - For most programming languages, the instruction set (also the entities' names etc.) are derived from the English language (for example: "for", "if", "table", "where"). It is common courtesy among developers to keep this standard, and also this ensures that the code is more readable for all programmers.
   - Since nowadays most development teams are international, it is difficult to maintain a proper workflow if each developer uses his / her native language. English, as a common language within a team, makes teamwork possible :))
   - Imagine your project requires 10 external libraries, and let's say each of these was written in a different language - how would your source-code look like? Not cool, right?

Hope you find this "how to" useful. Don't be shy and get back with your feedback!

Tags: Database  How To  Microsoft  SQL 


RobIII commented on 4/23/2014 1:37:44 PM

When not using parameterized queries (there's no excuse!) and insist on butchering strings together then always, *ALWAYS*, use ISO 8601 format. It's not only accepted and always understood correctly by MSSQL but also by other RDBMS'es as MySQL, PostgreSQL etc.

> "English is the most widely used language in the world"
No it isn't. Not even close. It's only spoken by 5.43% of the world's population (as native language) and only in third place. See


Alexandra commented on 4/28/2014 12:04:22 PM

Hi again :)

Also, as I've previously stated, ISO 8601 is the standard, however as not everybody follows this, errors may appear. Let's assume that you've received a legacy database backup for a project which contains over 200 stored procedures which did not use the standardized date format, but rather a localized version of the solution. Going through each takes time and resources, so my approach comes with a workaround for exactly this situation.

>> "English is the most widely used language in the world"
No it isn't. Not even close. It's only spoken by 5.43% of the world's population (as native language) and only in third place. See<<

Actually, what I meant to say was that English is the most widely used language when it comes to IT. I don't remember seeing many apps written in mandarin :)), although it would be interesting to debug such an application.


none commented on 4/24/2014 12:24:05 PM


This is being pretty naive saying that language should always be English. Setting the culture to English for the logins mess up quite a lot of things - for example start of the week and so on. How are you going to for example transparently support Thai dates in Thailand ? How about Persian or Ethiopian one?

It gets quite complicated if you are either doing SSAS or multitenant thing.

One solution is to maintain your own calendar - which many applications - especially financial ones do.
Calendars are complicated beasts.

csabababa commented on 2/2/2018 10:55:08 AM

I disagree with the trolls commenting your article(s).
It does have a point, there are many cases I came across this problem. Thanks for summarizing it

get more info commented on 10/30/2019 12:42:30 PM

I worth the audit. much valued! plentiful worried. in truth, happy in this fast article message. Cool.Thank you for the journal's internet site. much obliged! Fantastic.Thank you extremely for your message. Look after producing.

Your Comment:

Blog Home   SBP Home
RSS Feed       Contact


 Blog Archives  |  Terms of Use  |  Privacy Policy
© 2019 SBP Romania. All rights reserved.