Printable View
سلام Rasool-GH
قبل از ورود به سئوال شما , اشکال فرمت گزارش گیری ذیل چیه ؟
وقتی که فقط یک نام رو فیلتر کنید :
ضمیمه 135297
و زمانی که اطلاعات کل پرسنل رو به صورت متوالی مشاهده کنید :
ضمیمه 135298
( فرمت بالا تغییر داده شده گزارش خود شماست )
موفق باشید
سلام
یک نمونه دیگه با ریپورت جدید ضمیمه کردم شاید مورد سوال بنده بهتر مشخص بشه .
در نمونه مشاهده میکنید که حاصل گزارش که در نهایت باید روی یک فرم پرینت بشه در گزارش رکورد گرا مشکلی نداره و مقصود براورده میشه در حالی که در گزارش نرمال شده امکان تجمیع اطلاعات در یک فرم از دست میره . این مشکل وقتی بیشتر بروز میکنه که از جدول دیگه ای به طور مثال بخوایم نام فرزندان فرد رو استخراج کنیم و در همین فرم اونها رو هم داشته باشیم
شاید این توضیح لازم باشه که به دلیل سیستم استاندارد و ISO مستقر در هر سازمان امکان تغییر طراحی فرم به دلخواه وجود نداره
سلام rasool-gh
از ابتدا به انتها بیام بهتره
تغییر فرم در نهایت با صدور یک تغییر در مدرک وارده که الزاماً این کار در هر سازمانی امکان پذیرهنقل قول:
شاید این توضیح لازم باشه که به دلیل سیستم استاندارد و ISO مستقر در هر سازمان امکان تغییر طراحی فرم به دلخواه وجود نداره
گو اینکه در ممیزی نیز حداکثر توسط ممیز در صورت کشف عدم تطابق ظاهری بین فرم جاری و مستندات مرجع , منجر به یک OBS خواهد شد و نه CAR
:.:.:.:.:.:.:.:.
من اصلا متوجه منظورتون در خصوص اصطلاح رکورد گرا در داخل اکسس نمیشم , اگه منظورتون Record Oriented هستش , جای مطرح کردنش در اینجا نیست
فرمودید :
من برعکس این رو در داخل فایل میبینم ( مقاله آموزشی رو هم که خودتون در داخل پست 44 قرار دادید )نقل قول:
توضیحی که لازم به نظر میرسه اینه که گزارش 1 حاصل از یک پایگاه رکورد گراست و گزارش 2 نتیجه یک پایگاه نرمال شده است
:.:.:.:.:.:.:.:.:.
اشکال کار در اینجا قرار داره که میخواید کل یک پروسه رو یکجا جا حل کنید در حالی که بسیاری مسائل رو میبایست به صورت تفکیک شده , فرضا بخشی رو در سطح جدول ,بخشی رو در Query و بخشی رو هم توسط گزارش و یا کدنویسی به انجام برسونید
هیچ یک از این بخشها قادر به پیاده سازی راه حلهای مسائل پیچیده به صورت مستقل نیستند
گو اینکه بنده هنوز , اصلا پیچیدگی در خود سئوال شما نمیبینم , بلکه بیشتر پیچیده کردن مساله رو میبینم
به محدودیت 26 ارتباط داخلی جداول اشاره کردید , به شخصه تاحالا در هیچ دیتابیسی به این سطح از ارتباطات نرسیدم , اگر رسیدید یا تفکیکها غلط هستند یا ارتباطات غیر الزامی ( در واقع بدون اونها هم ممکنه بتونید )
از روی صورت مسالتون نمیتونم به این نتیجه برسم که در حال طراحی یک فایل با پیچیدگی مورد بحث باشید ، بر همین اساس چیز خاصی هم به ذهنم نمیرسه
:.:.:.:.:.:.:.:.:.
با تفسیری که بنده از کلمه سیستماتیک دارم , ما چیزی به اسم روش سیستماتیک , در این مبحث نداریم , شاید در برخی بخشها , Wizard ها رو بشه نمودی از راهکارهای سیستماتیک معرفی کرد , ولی در اینجا موضوعیتی ندارندنقل قول:
خلاصه سوال اینه که بعد از تفکیک اطلاعات در جداول مختلف بر اساس قواعد نرمال سازی ایا روشی سیستماتیک و استاندارد برای تشکیل یک رکورد واحد از اطلاعات تفکیک شده برای استفاده در گرارشات وجود داره ؟
در رابطه با استاندارد سازی باید به این نکته توجه داشته باشید که کل قواعد این مبحث ( نرمال سازی ) الزامی نیستند و تنها در حد توصیه قرار دارند
نرمال سازی مزایایی داره و در کنارش معایبی ولی به روشی از استخراج و کنترل اطلاعات اشاره داره که لزوما تنها راه کار نیز نیست ( ولیکن در اکثر موارد هوشمندانه ترین راهکاره )
خیلی از بانکهای اطلاعاتی رو میشه دید که بدون حتی یک ارتباط در سطح جدول , طراحی و پیاده سازی شدند
استفاده از سری توابع Domain Aggregate ( که Dlookup نیز یکی از اونهاست ) در داخل Select Query ها در وضعیتی که تعداد رکوردهای هدف زیاد باشه , اصلا مطلوب نیست ولیکن یکی از راه حلهاست
ولیکن در نهایت تنها به جهت یک راهنمایی کلی به یک نکته اشاره میکنم که میتونید با جستجو در سطح اینترنت به منابعی از اون دست پیدا کنید
مبحثی که ندیدم این تالار به اون ورود داشته باشه مبحث Sub Query هستش
در مبحث Sub Query با فرایندی غیر متعارف از به کارگیری یک پرس و جو در داخل یک پرس و جوی دیگه آشنا خواهید شد
قدرت واقعی پرس و جوها در این مبحث نهفته هستش , اگر مساله ای در سطح Query ها توسط این فرایند قابل حل نباشه , غیر ممکن خواهد بود که شما با کاربردهای عادی پرس و جوها بتونید به راه حل دست پیدا کنید
Sub Query ها قدرتمند هستند ولی به همون نسبت , هم در پیچیدگی کاربرد و هم در درک پروسه همراه هستند که همین امر یادگیری و آموزش کلی اون رو دشوار میکنه ولیکن مطالعه اون رو به شما توصیه میکنم
:.:.:.:.:.:.:.:.:.:.:.:.
تصور میکنم از همون روش قالب بر Report1 استفاده کنید ( حالا هم اسمی میخواید روی اون روش بذارید ) , این روش استاندارد تر از روش دومتونه
پی نوشت یک :
صورت مساله رو حداقل برای خودتون کاملا شفاف کنید , سئوالتون و تغییرات اون به گونه ای هستش که شما رو داره با یک گزارش داینامیک تلاقی میده
وقتی جواب یک بخش به شما داده شده در ادامش دیدم به نوعی نوشتید ( استنتاجی ) که حالا اگر تعداد متغیرها تغییر کنه اونوقت ....
این یعنی تغییر ترکیب بندی گزارش که میتونه شما رو به سمت یک مساله پیچیده و بی راه حل سوق بده
اگر این باشه شما قطعا در صورت ارائه هر گونه راه حلی , در مقاطعی با بن بست مواجه خواهید شد
پی نوشت دو :
گزارشی که بنده به عنوان معادل گزارش یک شما قرار دادم خیلی با نمونه شما فرق داره , یک مقدار به ظاهرش دقت کنید . با نمونه خودتون مقایسه کنید .
شما در گزارشتون از گروه بندی به حهت خلاصه سازی اطلاعات استفاده نکردید
میتونید بخشی از خلاصه سازیها و حذف اطلاعات تکراری و کم اهمیت رو در سطح Report به انجام برسونید
موفق باشید
سلام . جناب پیروزمهر .
بنده اصطلاح رکورد گرا رو از همین تاپیک در پست 7 عنوان شده برداشت کردم .نقل قول:
1- حذف گروه های تکراری:
فرض کنیم قصد داریم یک بانک اطلاعاتی کوچک برای یه شرکت فرضی به منظور نگهداری سوابق کارکنان طراحی کنیم که البته سوابق آموزشی اونها نیز توش درج بشه. اگر یک پایگاه داده رکوردگرا (سریع) طراحی کنیم قاعدتا یه چیزی شبیه زیر میشه:
در مورد شماره گزارشات هم اشتباه از بنده بوده . به همین دلیل فایل رو با اسامی جدید اصلاح کردم
حرف شما کاملا صحیحه . خودم هم به همین نتیجه رسیدم که طراحی غلط بوده و به همین جهت به سمت نرمال سازی اومدم . متاسفانه نحوه طراحی کل جدول که به اصطلاح رکوردگرا ازش نام میبرم لزوم وجود این تعداد ارتباط و حتی بیشتر رو ایجاد کرده.نقل قول:
به محدودیت 26 ارتباط داخلی جداول اشاره کردید , به شخصه تاحالا در هیچ دیتابیسی به این سطح از ارتباطات نرسیدم , اگر رسیدید یا تفکیکها غلط هستند یا ارتباطات غیر الزامی ( در واقع بدون اونها هم ممکنه بتونید )
منظور بنده از یک روش سیستماتیک چیزی شبیه اینه :
برای تفکیک اصلاعات یک جدول با تعداد ستونهای تکراری میشه هر قسمت رو در یک کوئری مجزا انتخاب کرد و بعد به وسیله کوئری انیون همه اون کوئریها رو زیر همدیگه تجمیع و در یک جدول اپدیت کرد .
حالا ایا امکان انجام همین کار به شکل معکوس هم وجود داره ؟
این روش به دلایلی که ذکر شد دیگه به بن بست رسیده (در برنامه اصلی که مربوط به یک برنامه سرویس و نگهداری تجهیزات میشه جدول شناسنامه تجهیزات 120 ستون داره و جدول اندازگیری پارامترهای همون تجهیزات هم 150 ستون داره ) بنده ناچار به سمت تفکیک جداول رفتم و بسیاری از مشکلات در محاسبات و گزارشات رو تونستم حل کنم . اخرین قسمتی که به مشکل برخوردم همین قسمت هست که شناسنامه تجهیز رو باید چاپ کنم .نقل قول:
تصور میکنم از همون روش قالب بر Report1 استفاده کنید ( حالا هم اسمی میخواید روی اون روش بذارید ) , این روش استاندارد تر از روش دومتونه
صورت مساله چون موارد زیادی رو در بر میگیره به طور کامل مطرح نکردم و خواستم که قدم به قدم جواب رو به دست بیارم . اگر در حوصله این بحث باشه هم برنامه و هم صورت کلی مساله رو مطرح خواهم کرد .نقل قول:
صورت مساله رو حداقل برای خودتون کاملا شفاف کنید , سئوالتون و تغییرات اون به گونه ای هستش که شما رو داره با یک گزارش داینامیک تلاقی میده
وقتی جواب یک بخش به شما داده شده در ادامش دیدم به نوعی نوشتید ( استنتاجی ) که حالا اگر تعداد متغیرها تغییر کنه اونوقت ....
در پایاننقل قول:
گزارشی که بنده به عنوان معادل گزارش یک شما قرار دادم خیلی با نمونه شما فرق داره , یک مقدار به ظاهرش دقت کنید . با نمونه خودتون مقایسه کنید .
بحث قالب ثابت فرم رو به همین منظور مطرح کردم . در این روش که شما اقدام به دسته بندی کردید باید اطلاعات رو در ریپورت به قسمتهای Page Header و Code Header و Details تقسیم کرد در حالی که فرم مورد نظر رو نمیشه در این سه بخش تفکیک شده تقسیم کرد .
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
برای اینکه بحث گره نخوره بهتره از اول شروع به بررسی صورت مساله کنیم .
برای سوال زیر پیشنهاد شما برای طراحی جداول چیه ؟
در گام اول :
تعداد 3000 دستگاه الکتریکی داریم که مشخصات فنی اون شامل 50 ایتم (نام . نوع . شماره سریال . سال تولید ...) هست و به این دستگاه یک کنتور و متعلقات مربوطه (مشخصات شامل 20 ایتم) و تعدادی کابل در ورودی (از 1 تا 5 کابل) و تعدادی کابل خروجی (از 1 تا 20 کابل) متصل میشه که مشخصات هر کابل به تنهایی شامل 10 ایتم میشه . کلیه این مشخصات یعنی تمام ایتمهای دستگاه و کابلها و کنتور باید روی یک فرم قابل مشاهده و پرینت باشه . من برای این منظور یک جدول ساختم و همه این موارد رو در یک رکورد ذخیره و بازیابی میکنم (کاملا روشنه که تعداد بسیار زیادی از فیلدهای هر رکورد خالی میمونه ). در مبحث استاندارد سازی کاملا واضح هست که برای ذخیره این اطلاعات حداقل 3 جدول مجزا مورد نیازه . یکی برای دستگاه یکی برای کنتور و بعدی برای کابلها.
مشکل همینجاست که اگه مشخصات رو در سه جدول بشکنم نمیتونم همه اونها رو در هنگام چاپ فرم در یک رکورد واحد تجمیع کنم و روی فرم بیارم .
(نتیجه اینکه یا باید با روشی بتونم همه اطلاعات رو در یک رکورد تجمیع کنم و ریپورت رو طبق روال سابق طراحی کنم یا در گزارشگیر و طراحی ریپورت امکانی برای این کار وجود داره که بنده از اون بی اطلاع هستم و راهنمایی و اموزش دوستان رو میطلبه )
در گام بعدی :
فرمی قرار داره که باید اندازه گیری پارامترهای الکتریکی مربوط به دستگاه و کابلها داخل اون ذخیره بشه . که به ازای هر کابل 7 پارامتر داریم که باز هم بنده برای اینکه همه پارامترها رو در یک رکورد در اختیار داشته باشم جدولی با 175 ستون درست کردم در حالی که با قواعد نرمال سازی به جدولی با 9 ستون نیاز خواهد بود .
سلام Rasool-Gh
مشکل همینجاست که اگه مشخصات رو در سه جدول بشکنم نمیتونم همه اونها رو در هنگام چاپ فرم در یک رکورد واحد تجمیع کنم و روی فرم بیارم .
مگر Sub Report چه مشکلی داره ؟ هر Sub Report اطلاعات یکی از جداول رو به نمایش در میاره
مگر نه اینکه شما جداول رو بر مبنای محتوای اونها جدا کردید و بر همین اساس هم اطلاعات اونها قابل دسته بندی هستند ( فرضا اطلاعات کنتور یک دستگاه رو در جدول مربوطه ثبت و ضبط کردید )
شما یک گزارش اصلی دارید در داخل اون در قالب یک Sub Report اطلاعات فرضا کنتور و در قالب یک Sub Report دیگه اطلاعات مربوط به کابلها و ... به نمایش درخواهید آورد
الزام شما در تلفیق کل اطلاعات در داخل یک رکورد رو متوجه نمیشم
خدانگهدار
سلام . بنده با Sub Report کار نکردم . شاید پاسخگوی نیاز من باشه . ممنون بابت زمانی که اختصاص دادید .
بعد از بررسی Sub Query و Sub Report اگر به نتیجه نرسیدم باز هم زحمت میدم .
باز هم ممنون میشم اگر از هر دو موضوع بالا نمونه ای در اختیار بنده بزارید
سلام مجدد .
جناب پیروز مهر در موارد ذکر شده مطالعه کردم ولی به جواب نرسیدم .
نمونه فایلی از پروژه خودم ضمیمه کردم . ممنون میشم اگر هر یک از دوستان بتونه راهنمایی کنه .
در فایل ضمیمه شده فرم شناسنامه برای ورود اطلاعات هست و فرمی که اخر اسمش P داره برای پرینت استفاده شده . برای نمونه نرمال سازی جدول کابل رو از داخل جدول شناسنامه خارج کردم . حالا به وسیله دو جدول تفکیک شده چطور میتونم به نمونه خودم برسم
(( البته در گام بعدی به موضوع نرمال کردن جدول بارگیری میرسیم که کمی پیچیده تر خواهد شد ))
سلام مجدد .
موردی به نظرم رسیده که روش انجامش رو نمیدونم .
مطابق فایل ضمیمه چطور میتونم در فرم frmNormal تعیین کنم که مثلا در تکس باکس خروجی 1 اطلاعاتی رو نمایش بده که شماره خروجیش در کوئری 1 هست ؟
سلام خدمت اساتید محترم و تشکر بابت مطالب آموزندتون
من تازه اکسس رو باهاش آشنا شدم و پس از مطالعه این پروژه آموزش رو که شامل درس . مطالب درسی.. دانشجو .. استاد هست رو درست کردم می خواستم ببینم ایردش کجاست؟ضمیمه 143388