gavan قام بنشر أكتوبر 2 مشاركة قام بنشر أكتوبر 2 مرحبا ,, هل هناك طريقة لتكوين تقرير موحد بين جداول او استعلامات لدي اربع جداول اثنان منهم مرتبطين مع الاثنان الاخرين بطريقة جداول التقاطع المهم تكوين تقرير موحد مفصل لكل شخص يبين تحته المراحل وكل عمليات السعر و الدين , مثلا احمد المرحلة الاولى مجموع السعر و مجموع الدين المرحلة الثانية مجموع السعر و مجموع الدين وهكذا بالنسبة ل كمال و محمد هل يمكن الوصول الى مثل هكذا استعلام او تقرير , ولكم مني اجمل شكر و تقدير 221.accdb رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 2 الكاتب مشاركة قام بنشر أكتوبر 2 ياجماعة الخير انا سويتها بالطريقة كما في المرفق انشاء جدول Appended_Table يستقبل البيانات من استعلامين الحاقيين وهما ل مجموع لسعر و مجموع الديون انشاءت استعلام مصدر بياناته من Appended_Table يحتوي على فلترة في الاسم وبهذا وصلت الى النتيجة المطلوبة , هل من مراجعة على الطريقة كونها تفضل طريقة ؟؟ تحياتي 221.accdb رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 2 مشاركة قام بنشر أكتوبر 2 نصائح الخبراء هنا كثيرة بخصوص اول خطوة في البرمجة وهي الجداول يرددون دوما يجب الاهتمام بتصميم الجداول وخاصة التسميات ولكن الكثير من المبتدئين لا حياة لمن تنادي .. وكأن توجيهات الخبراء لا تعنيهم اخي الكريم .. من الاخطاء التي وقعت فيها : 1- تسمية الكائنات بكلمات محجوزة في اكسس مثل Name ولم تكتف بتسمية الجدول بهذا بل سميت الحقل به 2- جميع الحقول المرتبطة في الجداول الثلاث متشابهة في التسمية ، وهذا لا يصلح لأنك ستواجه عقبات مستقبلا في الربط فلا تستغرب اذا تأخر رد الاخوة الاعضاء .. ------------------------------ تفضل هذا مطلوبك بعد تعديل الاخطاء .. استعلام واحد اجعله مصدرا لتقريرك 222.rar 2 رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 2 الكاتب مشاركة قام بنشر أكتوبر 2 2 ساعات مضت, ابوخليل said: نصائح الخبراء هنا كثيرة بخصوص اول خطوة في البرمجة وهي الجداول يرددون دوما يجب الاهتمام بتصميم الجداول وخاصة التسميات ولكن الكثير من المبتدئين لا حياة لمن تنادي .. وكأن توجيهات الخبراء لا تعنيهم اسف اخي الكريم والله لم الاحظ ذلك , انا في المثال كونت ملف وجداول فقط لكيفية العمل ولكن البرنامج الحقيقي التسميات مختلفة جدا صح مثالك جيد جدا وهو المطلوب ولكن لدي سوال هل طريقتي في الحل صحيحة , وهي : انشاء جدول Appended_Table يستقبل البيانات من استعلامين الحاقيين وهما ل مجموع لسعر و مجموع الديون انشاءت استعلام مصدر بياناته من Appended_Table يحتوي على فلترة في الاسم وبهذا وصلت الى النتيجة المطلوبة رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 2 مشاركة قام بنشر أكتوبر 2 هنا منتدى تعليمي .. نتعلم من اخطائنا ونزيد خبراتنا 2 ساعات مضت, gavan said: اسف اخي الكريم والله لم الاحظ ذلك , انا في المثال كونت ملف وجداول فقط لكيفية العمل ولكن البرنامج الحقيقي التسميات مختلفة جدا صح مثالك جيد جدا وهو المطلوب ولكن لدي سوال هل طريقتي في الحل صحيحة , وهي : انا اتكلم عن المثال الذي امامي ولا اعلم عن برنامجك الحقيقي وتسمياته ، وانا اعلق واكتب ملاحظاتي .. ليس لك وحدك فقط ولكن لكل من يمر من هنا امل عزيزي ان تسامحني ويتسع صدرك لردي الحاد فقد يكون ثقيل على قلبك : طريقتك لا تمت للبرمجة بصلة .. مع انك وصلت لمطلوبك والسبب في صعوبة العملية هي طريقتك في تصميم الجداول من الأساس لماذا جعلت السعر في جدول والديون في جدول آخر ؟؟ اعتقد انه يسعها جدول واحد رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 2 الكاتب مشاركة قام بنشر أكتوبر 2 استاذي القدير البرنامج عبارة عن فواتير بيع و سندات قبض و ديون سابقة، لكل منها جدوله الخاص، اما عن طريقتي في الحل هي نفس طريقة إيجاد كشف حساب زبون ففي بعض البرامج شاهدتها تعمل على تكوين جدول جديد يتم الحاق البيانات إليها من جداول مختلفة ويتم تكوين استعلام من الجدول الجديد ويوضع فيه المعايير، تحياتي يالغالي رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 2 مشاركة قام بنشر أكتوبر 2 12 دقائق مضت, gavan said: ففي بعض البرامج شاهدتها تعمل على تكوين جدول جديد يتم الحاق البيانات إليها من جداول مختلفة ويتم تكوين استعلام من الجدول الجديد ويوضع فيه المعايير، وانا كذلك شاهدت مثلها .. ضعف التصميم عند الإنشاء يضطر المبرمج الى معالجة الأمر على هذه الطريقة مرغما .. ناهيك عن توظيف كثير من الاستعلامات ( الحاق /وحذف/ وتوحيد .. الخ) على كل حال .. الخبرة بمزاولة اي مشروع وتطويره لاحقا .. هذه الخبرة ستظهر لنا الاشياء السابقة التي من المفترض ان نتجنبها . 1 رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 3 الكاتب مشاركة قام بنشر أكتوبر 3 13 ساعات مضت, ابوخليل said: ضعف التصميم عند الإنشاء يضطر المبرمج الى معالجة الأمر على هذه الطريقة مرغما .. ناهيك عن توظيف كثير من الاستعلامات ( الحاق /وحذف/ وتوحيد .. الخ) استاذي الغالي ابو خليل الوردة ,السلام عليكم انا حقيقة درست في بادئة الامر منهج الاستاذ InternetMaster في الأسس العلمية لقواعد البيانات , موجودة على شكل PDF في الانترنيت وكونت بعدها برنامج للمخازن حسب الصورة في المرفقات , (حسب ما افتهمت من دراستي لمنهجه ,). باعتقادي الشخصي: انه مصمم بطريقة قوية جدا من ناحية التكامل و التماسك في العلاقات بين الجداول , وهذه يعتبر اهم ميزة اذا كان لدى استاذي القدير اي فكرة فارجوا ان لاتبخل علينا بالرد وساكون شاكرا جدا 🙏 طبقت فكرتك ايظا وكانت نتائجها جيدة جدا , بل و مذهلة v_price: Nz(DSum("price","Price_Pay","Number_ID2=" & [Number_ID] & " and Name_ID2=" & [Name_ID]),0) v_nmber: Nz(DSum("DionAmount","Dion","Number_ID3=" & [Number_ID] & " and Name_ID3=" & [Name_ID]),0) فقط من باب المناقشة وانت استاذنا الكبير ,وسامحني اذا طاولت في الكلام او اخطات في التعبير استاذي: اي نعم الطريقة التى اتبعتها معقدة ولكن وصلت الى النتيجة السوال هنا استاذي : هل البرنامج ضعيف في التصميم ؟؟ اذا الجواب نعم : فبالطريقتين وصلت الى الناتج واذا كان الجواب : لا , فحضرتك ذكرت الضعف في التصميم , ولكن انا ما يحيرني ايظا انك دكرت الجملة (ناهيك عن توظيف كثير من الاستعلامات) , نعم تقريبا بحدود 244 استعلام . وهل هذا يعتبر ضعفا ؟؟ وهذا هو مربط الفرس كل التحية و التقدير لك, و لهذا الصرح العظيم بكل اعضائة 💖 رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 3 مشاركة قام بنشر أكتوبر 3 منذ ساعه, gavan said: انا حقيقة درست في بادئة الامر منهج الاستاذ InternetMaster في الأسس العلمية لقواعد البيانات , موجودة على شكل PDF في الانترنيت وكونت بعدها برنامج للمخازن حسب الصورة في المرفقات , (حسب ما افتهمت من دراستي لمنهجه ,). باعتقادي الشخصي: انه مصمم بطريقة قوية جدا من ناحية التكامل و التماسك في العلاقات بين الجداول , وهذه يعتبر اهم ميزة انت صح باسلوبك ونهجك .. تبحث وتتعلم وتطبق ولكن هذه الطريقة في التصميم قديمة وانتهت والسبب ان فيها الزام ما لا يلزم السلبية فيها من ناحيتين : 1- تعدد الجداول 2- العلاقات من ناحية تعدد الجداول : فالتوجه الحديث هو نحو برمجة الجدول الواحد ما امكن ومن ناحية العلاقات : فالعلاقات وضعت من اجل منع ادخال بيانات مغايرة في النوع والتخصيص ، وتقييد المستخدم ، وهذا المنع والتحكم له طرق اخرى بعيدا عن العلاقات عن نفسي لا استخدم العلاقات بين الجداول بتاتا .. الا في حالات خاصة .. العلاقات مكانها الاستعلام عندما نجمع بين جدولين او اكثر اقتباس نعم تقريبا بحدود 244 استعلام . يا لطيف !! هذه كثيرة جدا حسب تصوري برنامج مشتريات ومبيعات وديون .. الاستعلامات الرئيسية التي تدور عليها معظم العمليات قد لا تتجاوز اصابع اليد الواحدة اما بقية الاستعلامات فتكون داخلية .. كل تقرير وداخله استعلامه الخاص 2 رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 3 الكاتب مشاركة قام بنشر أكتوبر 3 9 ساعات مضت, ابوخليل said: ولكن هذه الطريقة في التصميم قديمة وانتهت والسبب ان فيها الزام ما لا يلزم اخي الغالي مرحبا بك ثانية حسب علمي ان قواعد البيانات التي كانت تستخدم جدول واحد وبدون علاقات كانت قبل 1969, قبل مجيئ اليسد كود موسس قواعد البيانات العلائقية , حيث اسس 12 قاعدة من قواعد البيانات ولحد 2020 وبحسب علمي اقوى قاعدة بيانات في العالم معمولة ببرنامج السايبيز تستخدم 8 قواعد فقط من قواعده , انظر الى قوة عقل هدا المبدع ولكن في الاونة الاخيرة يمكن ان تكون طرق اخرى لجأت ثانية الى مابعد 1969 والله العظيم لا اعرف تحياتي لمساعدتك في كل شيئ استاذنا الغالي رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 3 مشاركة قام بنشر أكتوبر 3 علائقية .. نعم العلاقة من الأساسيات ، ولا يمكن تصور جدول ليس له علاقة بآخر الا ما ندر وهذا لا يعني الربط والقيود مثال قريب : مشاريع كبيرة تستخدم قاعدة بيانات sql لا نجد بين الجداول ربط الربط فقط في الاستعلامات وادخال البيانات ( صاحبة العلاقة) يتم التحكم بها بعدة طرق اعتقد لا تخفى عليك .. مثل مربعات التحرير ، والاختيار من القوائم .. والبيانات الآلية المحفوظة مسبقا .. وغيرها 1 رابط هذا التعليق شارك More sharing options...
gavan قام بنشر أكتوبر 4 الكاتب مشاركة قام بنشر أكتوبر 4 رائع جدا استاذي القدير، واخيرا وجدت شخصا اراجع معه الأفكار التي درستها مسبقا في قواعد البيانات، يالغالي ابو خليل : الدراسة التي درستها تنص على ان: الاستعلامات و النماذج و التقارير خزعبلات يمكن تغيرها بسهولة وفي أي وقت، وان القرار الأكيد يكمن في طريقة ربط الجداول، سواء كنت تستخدم اي برنامج من برامج قواعد البيانات، وهنا معك الاحظ العكس تماما، هنا يمكن أن نستفيد من دراسة الأفكار و التحليل والوصول إلى الطريقة الصحيحة للبدء بشتى المجالات في قواعد البيانات، أكرر اشكرك جدا على رحابت صدرك في هذا الصرح لمناقشة و تبادل الخبرات، تحياتي 🌹🌹 رابط هذا التعليق شارك More sharing options...
ابوخليل قام بنشر أكتوبر 4 مشاركة قام بنشر أكتوبر 4 لا اخفيك .. انني احيانا اخالف القواعد الرئيسية في التصميم كقاعدة بيانات علائقية والسبب اني خرجت بنتائج مذهلة في سهولة حصر البيانات وتدفقها مثلا : من المعلوم لأي خبير الابتعاد عن تكرار اي حقل موجود .. فحسب النظام يمكنني جلب قيمة هذا الحقل من اي مكان في المشروع ولكن في حالات خاصة وجود هذا الحقل في جدول وادراجه ايضا في جدول أخر كجدول التفاصيل مثلا يسهل علي استخراج نتائج بصورة سهلة مذهلة وكنت سأحتاج الى عمليات كثيرة واستعلامات لو لم يكن موجودا . ولكن بشرط ان لا يكون للمستخدم علاقة بقيمة هذا الحقل . وغالبا لا يراه المهم ان نتفق ان الممارسة والخبرة في (مجال معين ) .. تزيد من اتساع الأفق في التفكير .. وبعد الرؤية للنتائج والمخرجات . والتصور الكامل لجدوى هذا الحقل في هذا المكان من عدمه . رابط هذا التعليق شارك More sharing options...
الردود الموصى بها
من فضلك سجل دخول لتتمكن من التعليق
ستتمكن من اضافه تعليقات بعد التسجيل
سجل دخولك الان