در عمر چند ده ساله کامپیوتر و گسترش برق آسای آن، بدون هیچ اغراقی سیستم عامل داس را باید مقوله ای باستانی محسوب کرد. سیاه مشقی بود که میکروسافت به تقلید از سیستمهای عامل دیگر مرتکب شد تا در نهایت به ویندوز برسد، که امروزه جهانی شده است. ولی شاید کمتر سیستم عاملی مانند داس در عمر کوتاه خود توفیق یافت که بستری برای تولید نرم افزارهای کاربردی فراوان باشد. این ماندگاری طولانی دو دلیل داشت. دلیل اول زمان و نحوه ارائه محصول بود که برای PC IBM Compatible تولید شد. تمام شرکتهای سازنده کامپیوتر بدون هیچ محدودیتی میتوانستند آن نوع کامپیوتر را بسازند و سیستم عامل داس را نیز روی آن بگذارند. ورود PC انقلاب جدیدی بود که در حاشیه خود با سیستم عامل خوش شانس داس، گره خورد. دلیل دوم، عدم پشتیبانی بعدی شرکت میکروسافت از این محصول مانند سایر شرکتها بود. مثلا امروزه تقریبا هیچ اثری از ویندوز سه وجود ندارد. گرچه ویندوز سه تحت داس اجرا میشد، ولی به مراتب مدرنتر از آن بود. اما تمام محصولات تولید شده در این محیط شانزده بیتی به راحتی قابل انتقال و تبدیل به محیطهای 32 بیتی بعدی بودند. اما داس به امان خدا ول شد. شرکت میکروسافت در این خصوص ید طولانی دارد و بسیاری از محصولات و استانداردهای خود را عملا از دور خارج کرده است. در صورتی که نرم افزار تحت یونیکس پنجاه سال پیش، امکان تبدیل و کامپایل در محیطهای بسیار مدرن یونیکسهای جدید را همچنان داراست.
از نسل باستانی کاران!، شاید فقط یک نفر در دنیا باقی مانده است که کارهای نشدنی می کند. و چنان پیوندی میان عهد عتیق داس و عهد جدید بانکهای اطلاعاتی و خروجیهای بسیار مدرن برقرار کرده است که خودش نیز از کرده خود، انگشت به دهان می ماند. آن باستانی کار تسلیم ناپذیر، من هستم!. کاری که اخیرا انجام داده ام و در ادامه توضیح خواهم داد، شاهد متوهمانه نباشد بگویم، اگر کسی بیل گیتس را مطلع کند که در گوشه ای از جهان، شخصی کمر همت به توسعه و مدرن سازی سیستم عاملی بسته است که او خود در کدنویسی آن شرکت داشت و اکنون در موزه ها به سر می برد، احیاء مجدد این سیستم عامل را در دستور کار میکروسافت قرار می داد!.
شرکتها و همکارانی که با سیستم توزیع و فروش من کار می کنند، می دانند که سالهاست این سیستم خروجی HTML و اکسل تولید می کند و به بانکهای اطلاعاتی مانند MS SQL Server نیز قابلیت اتصال دارد. طرح این نوع ارتباط در سال 1382 به ذهنم رسید و با دوست مستعدی که ابتکارات او با نبوغ پهلو می زند و اکنون ساکن امریکاست، مطرح کردم. ایشان با نوشتن یک Object جدید بدون اینکه هسته اصلی سیستم تغییر کند، عملا تمام گزارشهای سیستم را به این نوع خروجیها متصل کرد. در ادامه این طرح بحث رله کردن اطلاعات میان این سیستم و سایر سیستمها نیز با موفقیت انجام شد. هسته اصلی برنامه های انتقال اسناد حسابداری و ترمینال دستی، همین واسط رله کننده میان سیستمهاست. چند سالی است که می کوشم از این امکان بهره دیگری ببرم. و آن این است که تمام خروجیهای سیستم را از گزارشها تا فرمهای چاپی، مطابق سلیقه کاربر و بدون هیچ تغییری در طرف فروش و بانک اطلاعاتی مشتری، مستقیما به صورت جدولی در محیط اس کیو ال سرور بفرستم. امکانی که حتی در بسیاری از سیستمهای مدرن نیز وجود ندارد. ابتدا حسب پیشنهاد همکاری، بنا را بر نصب یک برنامه کمکی در طرف دیتابیس گذاشتیم، که البته پیچیدگی دیگری بر شرایط موجود می افزود. النهایه تمام اقدامات را در طرف سیستم توزیع و فروش انجام دادم. تنها شرط استفاده از آن، اتصال سیستم فروش به دیتابیس سایر سیستمهای موسسه است. شرکتهائی که از ترمینال دستی و یا سیستمهای شرکت ITC استفاده می کنند عملا این ارتباط را دارند و سایرین نیز می توانند نسبت به این ارتباط اقدام کنند. این بخش در سیستم فروش همواره قابل دسترسی است. نحوه استفاده از این امکان جدید به ترتیب زیر است :
1- اتصال به بانک اطلاعاتی مورد نظر برقرار باشد.
2- اسکماهای مورد نیاز سیستم فروش در طرف دیتابیس وجود داشته باشد. برای این منظور در خود سیستم چنین امکانی اضافه شده است. مدیریت – مشخصات سیستم – ارتباط با بانک اطلاعاتی – SD Schema
3- محل واسط میان سیستم فروش و بانک اطلاعاتی باید روی سروری باشد که SQL Server در آن نصب است. این اجباری است که Bulk Insert ایجاد می کند. البته از طریق Map کردن هم شاید بتوان این کار را کرد و برای پرهیز از هر گونه مشکلی اگر مسیر Relay Query مستقیما روی سرور بانک اطلاعاتی نیست، میتوان جداگانه چنین مسیری را به سیستم فروش معرفی کرد. بدیهی است که این مسیر باید اشترک گذاری و با دسترسی کافی تعریف شده باشد. مدیریت – مشخصات سیستم – ارتباط با بانک اطلاعاتی – مسیر واسط جداول موقت.
4- در هر گزارشی اگر گزینه ای غیر از گزارشهای معمولی انتخاب شود و البته گزینه Text با جداکننده Tab بیشتر توصیه می شود، و گزینه خروجی SQL تائید شود در این صورت متناسب با نام انتخاب شده برای گزارش، جدولی در طرف SQL Server و با همان نام، تحت اسکمای SDR تولید خواهد شد.
5- اگر جدول تولید شده را متناسب با گزارش ReStructure کنید، در گزارشهای بعدی به همین وضعیت جدید تعریف شده شما، استناد خواهد شد. نام فیلد و ایندکس و Relation و مشخصات فیلدها تماما می توانند تغییر منطقی کنند. تنها محدودیت در تعداد فیلدهاست که نباید کم و یا زیاد شود. شاید زیباترین ابتکار در این توسعه همین قسمت و استفاده از فرمها باشد.
6- در فرمها چاپی دست کاربر از گزارشها نیز بازتر است. برای همه همکاران فرم نمونه PFSQL را خواهم فرستاد. اگر برای آزمایش، این فرم را به عنوان فرم فاکتور به مشتریان منتسب کنید، مشاهده خواهید کرد که چگونه میتوان از یک فرم فاکتور چندین جدول متناسب ساخت که اطلاعات اصلی فاکتو و Detail محصولات و تخفیفات و افزاینده ها در آن مشخص شده است. همکاران اگر همت کنند، میتوانند با ابزارهائی مانند کریستال ریپورت تمام خروجی های سیستم را Online چاپ بگیرند. بهتر می دانید که علیرغم تمام امکاناتی که ایجاد شده است چه محدودیتهای طاقت فرسائی برای چاپ با فونتهای مختلف داریم. در فرمهائی که برای این موضوع طرح می شود علاوه بر گزینه WindosForm باید Delimaiter فرم نیز در هدر آن مشخص شود. در فرم نمونه این موضوع قابل مشاهده است. در هر نقطه ای از فرم اگر جدول خاصی مورد نظر باشد با کلمه رزرو شده TableName نام آن مشخص خواهد شد. پیش فرض در ارسال این است که ابتدا جدول متناظر خالی می شود ولی اگر منظور غیر از این بود در ادامه نام جدول عبارت :A باید اضافه شود. تکرار می کنم تمام این امکانات در فرم نمونه ارسالی، استفاده شده است.
با سلام
پاسخحذفانچه كه بنده با همين سواد ناچيز كامپيوتري ام ميفهمم
اين است كه جان كندني را بايد كند با وصله پينه هم درست نميشود بابا اينقدر بالا پايينش نكن بخدا از جايزه اسكار خبري نيست همش كه شد ويندوز و اس كيو ال و اكسل اپليكيشنشم درست كن هم ما راحت شيم هم بيل گيتس...
بعضی ها را باید به جبل عامل تبعید کرد!!!
پاسخحذف