[no Bug] MS SQL: no unicode for default setup (1 Viewer)

[Vasilich]

MediaPortal Version: 1.1 RC1
MediaPortal Skin: Blue3 wide
Windows Version: Win7 ultimate 32bit
CPU Type: Atom 330, 2x1.6 GHz
HDD: Samsung 5k4, 500 GB
Memory: 4GB DDR3 1333
Motherboard: ASRock ION330
Video Card: Nvidia ION (GeForce 9400)
Video Card Driver:
Sound Card:
Sound Card AC3:
Sound Card Driver:
1. TV Card: Digital Devices Cine S2
1. TV Card Type: 2x DVB-S2
1. TV Card Driver: 1.3.9.2
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec:
MPEG2 Audio Codec:
h.264 Video Codec:
Satelite/CableTV Provider: Astra 19.2, HotBird 6/7/8
HTPC Case: Joy-IT/Foxconn RS224
Cooling: BeQuiet 120mm
Power Supply: FSP 150W with modded fan
Remote: X10
TV: Panasonic TX-P50V10E
TV - HTPC Connection: HDMI

there is no unicode in MS SQL server when using it for mediaportal
Steps to reproduce:
1. Install MP 1.1 RC1
2a. configure some folders for video location in MP config tool using unicode names (with symbols beyond current system codepage (ACP))
2b. other variant- configure WebEPG to grab channel EPG with unicode information

Expected result:
you should see unicode symbols (im ny case it was mix of german and russian chars)

What happens instead:
you see question marks instead of that symbols beyond current system codepage

Additional info:
It doesn't happen to MySQL Db because in Gentle config there is
<DefaultProvider name="MySQL" connectionString="Server=NEW-XP;Database=MpTvDb;User ID=root;Password=MediaPortal;charset=utf8;Connection Timeout=300;" />
and it seems that MS SQL takes current system codepage as collation rule when creating DB where collation isn't explicitly defined. I may be wrong it my thoughts though.

 

[arion_p]

MSSQL does not support utf-8 encoding. Instead it uses Unicode (UCS-2 IIRC). This is not an encoding but rather a different field type, so it cannot be configured globally. The real problem however is that contrary to utf-8, Unicode uses 2 bytes per character for all characters (even the ones in the latin-1 charset). This means that all text data will occupy twice the space and consume twice the bandwidth even for those who do not need Unicode text.

It has been extensively discussed among Team members how much the extra overhead would impact low end systems and what alternatives exist. Since you can use MySQL to achieve the same effect without burdening the systems that have no use for Unicode, we have concluded that it is better we leave MSSQL as ANSI only. If you need Unicode / utf-8 use MySQL.

As a last alternative, it is always possible to use SQL Server Management Studio (Express) to change related fields from varchar() to nvarchar(). Note however that the resulting installation/database cannot be supported by the Team, so if you do it is at your own risk.

Don't report any bugs when using a modified database.

 

[Vasilich]

I fully understand reasons of that. And I moved back to MySQL already, having no unicode problems since that.
I just think that it should be clearly stated in the MP installer (when it asks for the type of database that will be installed/used) and in MP doocumentation , that MP doesn't support unicode type used in MS SQL Server.