انجمن‌ها

سلام

زبان سیستم فارسی است - اصولا کار با داده‌های "حرفی" و "متنی" به Locale وابسته است. هم در تبادل داده‌ها و هم در مرتب‌سازی و مانند آنها، اینکه زبان اصلی سیستم چه باشد اهمیت زیادی دارد. اگر فقط منوها یا عبارت‌های ثابت و فرم‌ها فارسی بودند و به داده‌ها کاری نداشتیم (مثلا نرم‌افزار برای نمایش عکس یا موسیقی یا فیلم بود که زبان داده در آن اهمیت ندارد) نیازی به این کار نبود - اما برای ما چنین نبوده

بهانه‌ای که در این زمینه مطرح می‌شود، این است که در تنظیم locale در Windows گفته شده که این تنظیم برای non-Unicode است - این عبارت دقیق نیست. می‌دانید که تمام داده‌های ما Unicode ذخیره می‌شوند (در پایگاه‌های اطلاعاتی تمام فیلدها nvarchar تعریف شده‌اند). اما در کنار داده‌ها هم مجبور به تنظیم CodePage هستیم. متاسفانه تا پیش از SQL 2008، فارسی جزء CodePageهای MS-SQL نبوده است و به همین دلیل از عربی استفاده کرده‌ایم. حرف کاف را با دردسر درست کرده‌ایم اما حرف‌های ی و ه‍ کماکان به صورت نادرست sort می‌شوند. خلاصه اینکه Data بدون CodePage و Locale نداریم. حال که این محدودیت برقرار است یا باید در کنار تمام داده‌ها در Admin و Client (و بخش‌هایی از سرور) دائما CodePage را حفظ و مراقبت می‌کردیم و یا از کاربر می‌خواستیم (و کنترل می‌کردیم) که Locale را فارسی کرده باشد.

در این وضعیت همه کار ساده‌تر خواهد شد - در واقع امکان ذخیره موقت داده‌ها به صورت Ansi ولی با حفظ اطلاعات فارسی میسر است. در Client و با CodePage شماره 1256 به همین وضعیت سریع و مطلوب رسیده‌ایم.

ممکن است در آینده ساختار Client و Admin را به نحوی تغییر دهیم که برای منوها و فرم‌های نیازی به Locale نداشته باشند - اما بعید می‌دانیم که حتی در آن زمان هم بتوانیم کاری کنیم که برای داده‌های فارسی به تغییر Locale وابسته نباشیم - حداکثر چنین خواهد شد که آن سیستم قادر است با داده‌های انگلیسی و داده‌هایی که در Locale جاری Windows تعریف شده‌اند کار کند. مثلا اگر Locale لاتین باشد (حالت عادی Windows) می‌توان با داده‌هایی با زبان‌های اروپای غربی (به جز برخی از نکات زبان اسپانیایی) کار کرد - ولی مثلا درج داده‌های روسی در جایی از سیستم (احتمالا در ارتباط بین COM+‎ و SQL Server) با خطا مواجه خواهد شد.

ارادت