Robert, You expressed concern about not having unicode support on SQL Server. I looked into the matter and found that it does support unicode, but setting a datatype up as unicode cuts the effective storage capacity of the column in half. This is because a unicode column allocates two bytes for every character whether the text stored in the column is unicode or not. So, if you want to be able to sort and compare text and have unicode support for it, the best SQL equivalent for the MySQL datatype "MEDIUMTEXT" is "NVARCHAR (4000)". This will allow a maximum of 4000 characters to be stored in the column. I went through the schema and pulled out all of the columns that are specified as "MEDIUMTEXT" and would like your feedback on whether you think that the columns can be converted to NVARCHAR (4000) and still function properly. I will put some of my own thoughts as well. If you disagree, please let me know.
Table: Column: My opinion salutation text This should be okay. Who is going to provide a greeting more than 4000 characters in length? signature text This should be okay. Same as previous. article a_from Probably not okay, but I don't know its intended purpose and whether sort/compare is necessary. article a_body Same as previous. article_plain body Same as previous. standard_response text This should be okay. What response is going to be more than 4000 characters in length? auto_response text Same as previous. session value Will session value really take up 4000 characters? standard_attachment content Probably not okay. Will have to find workaround. notifications text This should be okay. Will notifications take more than 4000 characters? faq_item f_keywords Probably okay? faq_item f_field1 ? faq_item f_field2 ? faq_item f_field3 ? faq_item f_field4 ? faq_item f_field5 ? faq_item f_field6 ? The only other data type I had to modify was article_attachment content If you want unicode support for this column, it will be of type NTEXT (which supports maximum of 1,073,741,823 characters (1 GB). You originally had it specified as LONGBLOB (which I believe supports upwards of 4 GB). Is 1 GB of characters enough for this column? If it doesn't have to be unicode, then I can specify it as TEXT and get 2 GB of charaters into it. Let me know what you think. I am excited about this project and want to contribute as much as possible. _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
