اضافه کنم که فایل بالا مریوط به ى و ک فارسی است. اگر ی و ک عربی مد نظر است به این مطلب مراجعه کنید: (+)

سلام، در سطح ویندوز استفاده از kbdfa.dll استاندارد و اصلاح شده کفایت می‌کند (و مزیتی هم که دارد این است که به تمام برنامه‌های موجود به صورت یک دست اعمال می‌شود؛ بدون نیاز به کد نویسی). یعنی اگر این مورد همه‌گیر شود اصلا مشکلی نخواهیم داشت.
این فایل را هم از اینجا می‌توانید دریافت کنید: (+)

سلام
کاری که اکسس در اینجا کرده یا SQLite ایی که مثال زدم، مرتب سازی بر اساس کدهای یونیکد این حروف است و کار صحیحی (در بدو امر حداقل) انجام شده: (+)

کد یونیکد "ک" عربی = 1603
کد یونیکد "ی" عربی = 1610
کد یونیکد "ک" فارسی = 1705
کد یونیکد "ى" فارسی = 1740

یعنی این مرتب سازی بر اساس منطق ریاضی صحیح است؛ اما بر اساس فرهنگ ایران خیر. به همین جهت توسعه دهنده‌های بانک‌های اطلاعاتی مجبور شده‌اند تا مفهومی به نام Collation را ارائه بدهند که در بالا در مورد آن بحث شد. این Collation دیگر صرفا بر اساس منطق ریاضی کدهای یونیکد حروف، مرتب سازی را انجام نمی‌دهد، بلکه بر اساس ادبیات و فرهنگ زبان‌های مختلف کار مرتب سازی را انجام خواهد داد. SQL Server در این زمینه حداقل برای فارسی زبان‌ها یک Collation مخصوص را در نگارش 2008 خودش ارائه داده تا مرتب سازی صورت گرفته روی رشته‌ها دقیقا مطابق فرهنگ و ادبیات ایرانی باشد (برای سایر کشورها هم این نوع Collation ها پیش بینی شده).
در اکسس که مد نظر شما است این Collation به نام General Sort order مهیا است (در اکسس‌های جدید در قسمت فایل، options و سپس برگه‌ی general قسمتی هست به نام new database sort order که همین collation است) (+)
و اگر در این مورد خاص درست کار نمی‌کند باید با مایکروسافت مکاتبه کرد و این مسایل را توضیح داد.

@Payamin
من چون خودم این kbdfa مخصوص ویندوز 7 64 بیتی رو درست کردم (+)، به همین جهت .... یک نوع علاقه است :)

@Ali
خیلی امیدوار شدم ... :)
بله. ممنون. این یک باگ در پیاده سازی بود. هنگام استفاده از این گوش فرا دهنده‌ها، تنها به روز رسانی خواص یک موجودیت کافی نیست؛ بلکه باید حالت آن‌را هم به روز کرد تا NHibernate واقعا متوجه شود که چیزی تغییر کرده.
نسخه‌ی جدید را از همان آدرس قبلی ذکر شده دریافت کنید.

اتفاقا اضافه شدن Persian_100_CS_AS هم بر اساس پیگیری کاربران ایرانی بوده؛ بنابراین این نوع نامه نگاری‌ها واقعا تاثیر دارد و اهمیت می‌دهند.

بله. Collation نحوه‌ی ذخیره سازی و همچنین مرتب سازی و مقایسه‌ی اطلاعات رشته‌ای را مشخص می‌کند (کاری با تاریخ ندارد).
اما چندتا بحث هست. Collation های فعلی یا Collation های آتی.
مدل توسعه‌ی SQL Server باز نیست. به این معنا که مثلا تا سال 2008 طول کشید تا Persian Collation به آن اضافه شد (Persian_100_CS_AS ، آن هم فقط با هدف گیری قسمت مرتب سازی صحیح رشته‌ها) یا Collation فعلی SQLite در مرتب سازی یک سری حروف فارسی مشکل دارد (بر اساس کدهای اسکی حروف عمل می‌کند، چیزی که در SQL Server حل شده است به لطف وجود Collation مناسب). البته مدل توسعه‌ی آن باز است ولی ... من ندیم کسی این مورد را اصلاح کند و یک patch ارائه دهد.
هنوز کسی در مورد قسمت و مفهوم مقایسه‌ای رشته‌ها در Collations کاری نکرده است که جای کار دارد (مثلا ی و ى یکی درنظر گرفته شود).
ولی باز هم به عنوان راه حل جامع قابل قبول نیست. چون گیرم به نگارش بعدی اضافه شد، نگارش‌های قبلی چه کنند؟ سایر بانک‌های اطلاعاتی چکار کنند؟
به همین جهت یک راه حل ساده و بدون نیاز به منتظر ماندن و سازگار با تمام بانک‌های اطلاعاتی، یکسان سازی اطلاعات دریافتی است.

نه. از Collation ها هم کاری ساخته نیست. در این مورد اینجا بیشتر بحث شده : (+)

ضمنا این رو هم در نظر داشته باشید که بانک اطلاعاتی‌های گوناگونی داریم (فقط SQL Server را نباید مد نظر داشت) و ... هنگام تصمیم‌گیری باید یک راه حل کلی که همانا یکسان سازی دریافتی است را اعمال کرد.

اکثر سایت‌هایی که مشاهده می‌کنید (و عموما بر مبنای PHP هستند) مثل فوروم‌ها، وبلاگ‌ها و غیره، سورس باز هستند و یا مجوز GPL دارند یا احتمالا هم خانواده‌اند و مشکلی نخواهند داشت. در غیراینصورت اگر کار نهایی تجاری و سورس بسته باشد و شخصی هم گزارش بدهد و هاست هم در کشوری باشد که مسایل کپی رایت را رعایت می‌کند، سایت را معلق می‌کنند، به علاوه سایر مسایل قانونی مرتبط.

این مطلب جاری به معنای نفی استفاده از متغیرهای استاتیک نبود. اگر بد است چرا اصلا در زبان قرار داده شده؟ بنابراین با دید صرفا منفی به این قضیه نگاه نکنید.
در کار شما آیا این لیست برای تمام کاربران یکسان است؟ آیا سطح دسترسی در کار نیست؟ آیا همه موارد مشابهی را مشاهده می‌کنند؟ اگر بله مشکلی ندارد، فقط در نظر داشته باشید که متغیرهای استاتیک thread safe نیستند. برای این موارد کلاس Cache قرار گرفته در فضای نام System.Web.Caching ،‌ مطابق مستندات آن Thread safe است و read/write آن در یک محیط چند کاربره مشکل زا نیست: (+)

ضمنا در مورد طراحی سیستم چت خوب در ASP.NET در مورد COMET تحقیق کنید. این روش سربار کمی دارد چون سرور به کلاینت پیغام ارسال می‌کند نه اینکه کلاینت متناوبا سرور را چک کند که آیا پیغام جدیدی هست یا نه: (+)