انجمن‌ها

سلام

وضعیتی که در شکل فوق در پایگاه 2 مشاهده می‌شود مطابق رفتار سیستم و صحیح است. به دلیلی که به تاریخچه درج اطلاعات در پایگاه 1 (اصلاحات، برگه‌های اصلاح بها، تعدیل یا برگشت یا عوامل ناشناخته‌ی دیگر) مربوط است بهای خروجی را یک ریال بیشتر محاسبه کرده است. به بیان دیگر اگر سیستم اطلاعات پایگاه 1 را دوباره محاسبه کند (یعنی وضعیتی که در انتقال به پایگاه 2 به صورت احباری رخ داده است) به احتمال بسیار زیاد بهای خروج را یک ریال کمتر محاسبه می‌کند. با توجه به اینکه اتفاقاتی که منجر به این وضعیت در پایگاه 1 شده است را نمی‌دانیم (و صرفا با حاصل عملیات مواجه هستیم) نمی‌توانیم دلیل این وضعیت را توضیح دهیم. با توجه به تاریخ رخداد حدس می‌زنیم که عملیات احتمالا در نسخه‌های قدیمی سیستم در پایگاه 1 ثبت شده‌اند و اگر چنین باشد ممکن است نحوه‌ی عمل تحت تاثیر تغییراتی که برای رفع اشکال و خطا در کدها به عمل آمده است با نحوه‌ی عمل در نسخه‌ی کنونی تفاوت داشته باشد. اشکال هم، همانطور که مشاهده می‌کنید مربوط به گرد کردن آن دسته از اعداد اعشاری است که قسمت اعشاری (پس از ممیز) آنها به رقم 5 ختم می‌شود - مثل 2,102,712/5 که در پایگاه 1 به پایین و در پایگاه 2 با بالا گرد شده است.

متاسفانه بیش از توضیحاتی که در بالا دادم، نکته‌ی دیگری برای ذکر و راهنمایی ندارم. اگر توضیحات بیشتری از دلیل رفتار سیستم در پایگاه 1 به نظرتان می‌رسد یا به روشی می‌توانید وضعیت را بازتولید نمایید بفرمایید تا بیشتر روی آن کار کنیم.

ارادت

سلام .ممنون از پاسختان

شرمنده انگار در پست قبلی جای پایگاه 1 و 2 رو جابجا نوشتم. عذرخواهی

پایگاه سال 95 که همان سال ایجاد و برگه عملیاتی شده است مصرف رو عدد    2109712 محاسبه  میکنه.وقتی فایل گرفته و در پایگاه جدید فراخوانی و عملیاتی میشود همان مصرف 9109713 رو نشان میدهد.حتی برگه مصرف حذف  و دستی ثبت شد اما باز همین عددبود.هیچ برگه اصلاح بها و.. ثبت نشده است. هر دوپایگاه عملیات کالا یکسان است.

نسخه فعلی ما 902 و سرورمان از سال 95 تا الان همان است. مشخصات سرور    ،     ram 8G  , corei7-3.6Gh :Win7 ultimate 64

مشخصات کلاینتی که الان برگه رو عملیاتی میکنه:   ram 4G  , pentium G3250. :Win7 ultimate 64

سوالی دارم روند سیستم نوسا ، به چه صورته؟روند طبیعی؟

سوال دوم سرعت عملیاتی کردن و محاسبات برگه ها به سرور بستگی داره ؟

بازم ممنون از وقتی که میذارین.

سلام

خیلی ممنون از اطلاع‌رسانی و توضیحات تکمیلی.

جابجایی شکل‌ها من را به اشتباه انداخته بود و با این فکر که وضعیت جدید صحیح است پیش رفته بودم.

ابتدا پاسخ سوال دوم: بله - عملیاتی کردن و محاسبه‌ی برگه‌ها در سرور انجام می‌شود.

اما اصل داستان: در CPUهای Intel به صورت تاریخی و ثابت از یک روش روند خاص به نام روش "بانکدار" استفاده می‌شود. این گونه‌ای از روند طبیعی است که اعدادی که به اعشار بیش از نیم ختم می‌شوند را به بالا و آنها که به اعداد کمتر از نیم ختم می‌شوند را به پایین گرد می‌کند. اما در اعدادی که دقیقا به نیم ختم می‌شوند (مثل موردی که در این پست اشاره فرمودید) به گونه‌ای روند می‌کند که حاصل یک عدد زوج باشد. این روش روند در محاسبات اعشاری ما هم تاثیر گذاشته است و به همین دلیل حاصلی که از این محاسبه انتظار داریم و ذکر کردیم 2,102,712 است یعنی یک عدد زوج.

این روش بسیار ناکارآمد است (توضیح و دلیل را در ادامه ذکر خواهم کرد) اما به صورت تاریخی و از آنجا که داده‌های سیستم‌های مختلف (من جمله نسخه‌های قدیمی سیستم ما) به صورت طبیعی مبتنی بر Intel CPU از این روش استفاده می‌کنند ما مجبور به حفظ آن در محاسبات انبار هستیم. هدف این است که اگر داده‌های قدیمی دوباره پردازش شوند همان نتیجه را به همراه داشته باشند. در سیستم‌های جدید خودمان عملیات گرد کردن را شبیه‌سازی کرده‌ایم و از استاندارد Intel تبعیت نکرده‌ایم و از روند طبیعی (که نیم به بالا گرد می‌شود) استفاده کرده‌ایم.

اما دلیل ناکارآمد بودن روند به روش بانکدار: در رایانه اعداد اعشاری به صورت غیر دقیق ذخیره و پردازش می‌شوند - مثلا عدد 1.5 ممکن است به صورت 1.500000000001 یا به صورت 1.499999999999 ذخیره شود. به همین دلیل اعداد در مبالغ و مقدارهای ما هرگز به صورت اعشاری ذخیره نمی‌شوند؛ بلکه به صورت دقیق با تعداد ارقام از پیش مشخص ذخیره می‌گردند. در مبالغ 17 رقم و دو رقم اعشار و در مقدارها 15 رقم و چهار رقم اعشار داریم. اما در حین محاسبات (مثل تقسیم به نسبت مبلغ موجودی به مقدار خروج و مقدار موجودی که در محاسبه‌ی بهای کالای صادره داریم) ناچار به استفاده از محاسبات اعشاری در میانه‌ی راه هستیم.

با توجه به این نکات، روش بانکدار برای گرد کردن اصلا کارآمد نیست - چون اگر هر یک از حالت‌های 1.50000000001 یا 1.4999999999 پیش بیایند، عدد ما دیگر به نیم ختم نشده است و روش بانکدار کار نمی‌کند.

پس ممکن است ندرتا اعداد ختم شده به نیمی را مشاهده کنیم که به عدد فرد گرد شده باشند - چون روش بانکدار در تقریب‌های اعداد اعشاری دچار مشکل شده است.

این وضعیت به خودی خود ممکن است زیاد آزاردهنده نباشد - کما اینکه تا کنون هم نبوده است - "تا زمانی که" هر بار محاسبه نتیجه‌ی یکسانی را به بار آورد. اشکال، همانطور که شما هم اشاره فرمودید - دقیقا در زمانی رخ می‌دهد که تکرار محاسبه نتیجه‌ی متفاوتی را حاصل نماید.

حال به جنبه‌ی دیگری از ماجرا می‌پردازیم: تفاوت بین کدهای 32 بیتی و 64 بیتی. اشکالی که در اینجا با آن برخورد کرده‌ایم از همین تفاوت ناشی شده است. به احتمال بسیار زیاد در سرور شما نسخه‌ی 64 بیتی از سرور نوسا نصب شده است. اگرچه حداکثر تلاشمان را کرده‌ایم که نسخه‌های 32 و 64 بیتی نتیجه‌ی یکسانی به همراه داشته باشند اما در موارد نادری مثل آنچه در اینجا مشاهده می‌کنیم چنین می‌شود که در نسخه‌ی 32 بیتی نیم به صورت 0.499999999999 و در نسخه‌ی 64 بیتی به صورت 0.500000000001 محاسبه شده است. به همین دلیل در 32 بیتی (سروری که در سال 95 روی رایانه نصب بوده) به پایین و در 64 بیتی (احتمالا سرور کنونی شما) به بالا گرد شده است. البته اشکال اصلی در روش روند بانکدار است - متاسفانه اگر این روش را تغییر می‌دادیم، به جای موارد نادر، تقریبا همه‌ی اعداد فرد با اعشار نیم متفاوت (نادرست) می‌شدند. این روش را باید هر طور هست حفظ کنیم.

حتما این موارد نادر را بیشتر بررسی می‌کنیم و اشکال را در ویرایش بعدی سیستم برطرف خواهیم کرد. علی‌الحساب (اگر پیش‌بینی من در مورد سرور نوسای 64 بیتی) صحیح باشد می‌توانید موقتا (تا آمدن نسخه‌ی بعدی) سرور 64 بیتی را با Admin حذف کنید و سرور 32 بیتی را جایگزین نمایید. برای اینکار همکاران بنده در بخش پشتیبانی هم می‌توانند به شما کمک نمایند.

ممنون
ارادت

سلام
ممنون از پاسخ شما
مشکل ما با راه حل شما و کمک همکاران پشتیبانی حل شد.سرور 32 بیتی نصب و آیکن 32 بیتی استفاده شد.
ممنون