Multi-Language support - DBA

  • I am a DBA in North America. I'm going to soon work on a project with different collations and different language support may be a siginificant issue in interpreting logs. Example: What if I get a call for a german database running a german collation and the version for German and can't dissect the logs?

    Can some of you with this experience please help me understand what challenges I may face? I've only provided English support up until now.

  • My guess would be that the errror report /log files will read exactly as if they were in english EXCEPT in a differnt language soo i am thinking you may need to learn a new language(German) or have a person be able to read what is in the logs for you and translate while you move about that way. Its only a guess and good luck. =]

    DHeath

  • Hi Csoloway,

    You should use this translator.

    http://translate.google.com/#

    It helped me a lot when I used to have real hard times when working with Japanese servers with Japanese text everywhere.

    Thank You,

    Best Regards,

    SQLBuddy

  • There are several solutions:

    Customized messages: use customized error messages together with RAISEERROR and make sure to include the error number inside the error message. This will allow you to get the error message number and query sys.messages with message_id and the language_id of your choice.

    You should include the error number at a specific place in each error message (either at the beginning or at the end).

    System messages: You should get familiar with the more frequent error messages, but you don't need to learn a foreign language (it doesn't hurt, though... ;-))

    Once you recognized the pattern you can search sys.message for the text, get the message_id and query sys.messages for this id with the language of your choice.

    However, most system messages will be stored using the server language. So you might want to verify the language setting of the server your clients will use. (Side note: there is a good chance the SQL Server will be installed using english as the default language even if located in Germany so you don't have to worry about that part, hopefully - I know by experience ;-)).

    To summarize it: you need to spend some time to design the error message concept in general. Also, you should not use any LANGUAGE or DATEFIRST related functions (like DATEPART(dw/wk/ww) or DATENAME(Month/Week/Weekday)) in your code. There are alternatives available. This part is even more important than the error message stuff: in most cases you won't even get an error message when using DATEPART(dw,YourDate). The client would "just" get wrong results...



    Lutz
    A pessimist is an optimist with experience.

    How to get fast answers to your question[/url]
    How to post performance related questions[/url]
    Links for Tally Table [/url] , Cross Tabs [/url] and Dynamic Cross Tabs [/url], Delimited Split Function[/url]

  • Every error message in the error log has an error number that is the same in all language, you can use it to translate the message and you'll just have to fill the variable pieces (usualy db name, object name or path).

    You can also read the message with a severity above 19 in the application event log, this will also give you the error number but the variable part of the message can be queried alone (using powershell or a .net application).

    You'll have a problem with the custom error messages though, since they might be written in any language.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply