اذهب الي المحتوي
أوفيسنا
بحث مخصص من جوجل فى أوفيسنا
Custom Search

الردود الموصى بها

قام بنشر

هذا مثال بسيط عن استخدام الدالة dmax لعمل ترقيم مسلسل ، و نلجأ لهذه الطريقة عندما نريد السماح لنا بتعديل ترقيم المسلسل بسهولة

و لأنه يمكن فى حالة تعدد المستخدمين أن يتم حجز رقم و اظهاره فى النموذج من قبل مستخدم بناء علي القيمة فى الجدول ، بينما يحجز مستخدم آخر نفس الرقم ، لذا يتم اعادة اختباره قبل التسجيل

  • Like 2
  • Thanks 1
قام بنشر

السلام عليكم

بارك الله فيك أخي محمد على هذا المثال ولي ملاحظة على شكل سؤال :

أين الفحص عند الإضافة عن طريق زر إضافة سجل جديد كما هو في زر حفظ ؟ .

تحياتي .

قام بنشر

بالفعل نسيت اضافة دالة الاختبار الي الزر الآخر مثل زر الحفظ

تم التعديل باضافة السطر الي كود سجل جديد ليصبح

 Me.id = checkid()

 DoCmd.GoToRecord , , acNewRec

 Me.id = Nz(DMax("[id]", "names") + 1)
أي اضافة
 Me.id = checkid()

و أشكرك علي التنبيه :)

قام بنشر
أخي محمد ماذا لو عند فتح سجل جديد يكون رقم السجل الظاهر قد تم استخدامه من قبل مستخدم آخر  .

أعتقد أن الفحص قبل أمر فتح سجل جديد مطلوب .

اخي أبو هادي ، أرجو التوضيح أكثر

ما بنيت عليه الكود ، هو أن الرقم المحجوز علي النموذج يتم تغييره تلقائيا عند الحفظ أو الانتقال الي السجل التالي اذا كان قد تم تسجيله خلال فترة مليئ بيانات النموذج

و كذلك الحال بالنسبة للمستخدمين الآخرين ، فاذا كان الرقم الظاهر علي النموذج قد تم تسجيله ، فيتم استبداله عند الحفظ أو الانتقال الي سجل آخر باستخدام الدالة .

مع الشكر :d

قام بنشر

السلام عليكم

Private Sub Command5_Click()

[b] Me.id = checkid()[/b]

 DoCmd.GoToRecord , , acNewRec

 Me.id = Nz(DMax("[id]", "names") + 1)

End Sub

ما قصدته هو السطر الأول من الكود .. فلم أنتبه أنك أضفته واعتقدت أنك أضفت السطر الثالث فقط دون الأول :)

الآن المثال 100% .

طبعا لزيادة الاحتياط لو كان هناك أكثر من مستخدم وعملية الإضافة سريعة فسوف تكون عملية الفحص لمرة واحدة غير كافية مما يتطلب عمل تكرار للتأكد من عدم وجود أي خطأ أثناء الإضافة وحتى يتم التأكد تماما من الإضافة .

تحياتي .

قام بنشر (معدل)

السلام عليكم

أخي محمد طاهر .. ما قصدته في الإحتياط بعمل تكرار كالتالي :

Private Sub Command5_Click()

 On Error Resume Next


 Do

   Err.Clear

   If Me.NewRecord Then Me.id = checkid()

   DoCmd.GoToRecord , , acNewRec

 Loop Until Err.Number <> 2105


 Me.id = Nz(DMax("[id]", "names") + 1)

End Sub

مما سيكون أكثر انسيابا في العمل دون توقف وخصوصا لو صادف إثنان في إضافة نفس الرقم في نفس الوقت .

تحياتي .

تم تعديل بواسطه أبو هادي
  • Like 1
قام بنشر

هذا أفضل :yess:

و سأعيد التفكير فى الموضوع بصوت عال قبل تعديل المثال:

دالة الاختبار تقوم باستدعاء آخر رقم مسجل لمستخدم رقم1

فى زمن ز1

و نقارنها بما هو فى النموذج ، ثم تغير القيمة فى النموذج قبل الانتقال الي السجل التالي أو قبل الحفظ اذا لزم الامر

و عملية الانتقال و الحفظ تحدث فى زمن ز2

و المشكلة لو قام مستخدم رقم 2 بعمل الاختبار و التسجيل معا فى توقيت بين ز1 و ز2 ، فلو قام بعمل الاختبار بعد ز2 فسيأخذ رقم جديد و لو قام بالتسجيل قبل ز1 فسيكون الرقم الذي سجله قد أخذ فى الاعتبار

و هذا معناه تنفيذ الدالة بالكامل من قبل مستخدم 2 فى زمن تنفيذ جزء من الدالة ( ز2 - ز1 ) من قبل مستخدم رقم 1

و رغم أننا نتحدث عن أجزاء من الثانية ، الا أن وقوع الخطأ ممكن نتيجة لأي ظرف مثل اختلاف سرعة اداء الأجهزة مثلا ، فسيكون الزر الذي تفضل أبو هادي بوضع الكود الخاص باعادة الاختبار له فى وضع آمن ، حيث أن عدم التمكن من الذهاب للسجل الجديد معناه أن الرقم الحالي قد تم حجزه من قبل مستخدم آخر ، و سيتكرر الاختبار الي أن يتم حجز رقم غير متعارض .

و كود الاخ أبو هادي يعتمد علي اختبار حدوث خطأعدم امكانية الذهاب الي سجل جديد (الخطأ رقم رقم 2105 ) و هذا معناه أن الرقم تم تسجيله من قبل مستخدم آخر لذا لم يمكن حفظ السجل و الذهاب الي السجل الجديد ؟؟

و لكن سيكون مازال هناك خطأ وارد فى الزر الأول ( زر الحفظ ) . و الذي قد ينتج عنه استبدال بيانات سبق تسجيلها فى الجدول

أو هل يوجد اقتراح بديل بالنسبة لزر الحفظ ، و الذي حتي الآن سنضع فيه نفس الكود ثم اغلاق النموذج بعد التمكن من الذهاب الي سجل جديد دون حفظ الجديد .

أم هناك اقتراحات بديلة بتنفيذ الاختبار بطريقة أخري بالنسبة لزر الحفظ ؟؟

Private Sub Command4_Click()

On Error Resume Next


Do

  Err.Clear

  If Me.NewRecord Then Me.id = checkid()

  DoCmd.GoToRecord , , acNewRec

Loop Until Err.Number <> 2105


DoCmd.Close

    

End Sub

و الأن نقطة أخري للمناقشة ، هل الوضع هكذا أفضل

أم أن نجعل النموذج بددون مصدر بيانات و نسجل البيانات علي الطاير ؟؟

قام بنشر

توجد أمثلة علي طرق الاضافة الثلاثة من نموذج بدون مصدر بيانات ،و التي أحب أن أسميها اضافة علي الطاير

إضافة سجل باستخدام SQL من نموذج بدون مصدر بيانات

إضافة سجل باستخدام DAO من نموذج بدون مصدر بيانات

إضافة سجل باستخدام ADO من نموذج بدون مصدر بيانات

و هي آمنة من حيث تكرار الاضافة حيث أنها تعتمد علي الترقيم التلقائي ، و لكن تحتاج الي تعديلها الي نفس التطبيق من حيث استخدام Dmax مع حقل رقمي

و اضافة دالة الاختبار لكي تناظر الحالة التي نناقشها الآن

و ساقوم باعداد المثال بالطريقة الأخري ( بأجزائها الثلاثة ) قريبا بإذن الله :d ، فهل هناك طرق أخري يمكن اعتبارها ووضعها فى المثال للمقارنة الي الطبيعة غير الطرق الثلاث ؟؟

و ستبقي نقطة المناقشة أي الطريقتين أفضل ؟؟

و قد نستطيع مناقشتها من الآن أو تأجيلها لحين اعداد المثال

و طبعا المقارنة ستكون فى الحالة التي ندرسها حاليا ، و هي حالة الحقل الرقمي مع استخدام dmax للترقيم مع دالة الاختبار و ذلك لكل من حالتي النموزج المرتبط و النموذج الغير مرتبط ( الطاير ) :d

قام بنشر

السلام عليكم

مرفق المثال بعد التعديل

بالنسبة للنموذج الغير منضم أي الذي لا يوجد له مصدر بيانات

هنا بعد دراج السجل اذا لم يكن الرقم مكرر ، فلا توجد مشكلة ، و لكن لكون النموذج غير منضم ، لم أصل بعد لكيفية التعامل مع حالة عدم اضاف السجل نتيجة لتكرار الرقم ( سبق تسجيله من قبل فى الجدول ) أي البحث عن خطأ نتيجة لعدم الاضافة و مثلما فى مثال النموذج المنضم ، لا يمكننا الاعتماد علي مجرد اختبار وجود القيمة فى الجدول ، حيث أنه قد يضيفها مستخدم آخر بعد اختبارها

و هي فى الاغلب لها حل ، و لكن لم يحضرني حاليا فنشرت المثال لكي لا أتأخر ، و قد قمت بحل تحايلي فى حالة النموذج الغير منضم و هو التأكد من القيم المناظرة للرقم و مقارنتها فى الجدول بنظيرتها فى النموذج .

و بالنسبة للمثال السابق الخاص بالنموذج المنضم ، أضفت اليه التأكد من عدم ترك الاسم فارغ قبل التسجيل

و في انتظار إضافاتكم بخصوص كيفية التأكد من اضافة السجل من عدمه فى حالة النموذج الغير منضم ( أي اذا كان المسلسل موجود فلن يتم اضافة السجل ، و المطلوب هو كيفية معرفة هل أضيف أم كان موجود أصلا ، فى حالة النموذج الغير منضم .

( التي تناظر فى مشاركة الاخ أبوهادي معرفة حدوث الخطأ بالتحرك الي سجل جديد ، فسيرفض التحرك اذا لم يتم حفظ السجل الحالي لوجود نفس رقم المسلسل فى الجدول )

و لكن فى حالة النموذج الغير منضم

و حاليا تتم مقارنة الاسم فى النموذج ، بالاسم المسجل فى الجدول و اذا لم يكونا متطابقان يعطي رسالة خطأ فقط

و لم أضف عملية زيادة واحد و المحاولة مرة أخري ،ـ لأنه بدون طريقة رقم الخطأ ليس لدي تصور عن كيفية كمل حلقة للتجربة كما فى مثال النموذج المنضم

احد الحلول التي خطرت لي هو عمل حلقة 100 مرة مثلا ، لاستحالة ادخال 100 رقم متتالي مع عدد معقول من المستخدمين ، و لكن هذا الحل لم يعجبني ، فلم أنفذه فى انتظار اضافاتكم و أفضل أن نصل لحل مشابه لما فى النموذج المنضم

ملاحظة : تم تعديل المثال فى مشاركة تالية

مع تحياتي

قام بنشر

السلام عليكم

أخي الفاضل محمد .. لقد أضفت نموذج ثالث ، طبقت فيها فكرة جعل النموذج منضم قبل الإضافة ثم فك الإنضمام بعدها .

غير متأكد إذا هذه الفكرة ستنشئ مشاكل أم لا ، ولكني فحصتها ولم تواجهني مشاكل حتى الآن .

تحياتي .

ملاحظة : تم اعداد مثال مجمع فى مشاركة تالية

قام بنشر

شكراً لك أستاذي أبو هادي والشكر موصول للأستاذ محمد طاهر

قمت بتجربه جميع البرامج الخاصة بالترقيم التلقائي والعمل على الشبكة ولكن واجهتني مشكلة وهي عند إدخال إسم يتم تسجيل الرقم 10 في الجهاز المدخل عليه الأسماء وفي نفس الوقت عند تسجيل إسم في جهاز آخر على نفس البرنامج يكون الرقم الظاهر 10 أي يتضح أنه لم يحجز الرقم 10 للمسجل الأول هذا مبدئياً ولكن بعد الخروج من البرنامج أو إختيار إضافة سجل يتغير الرقم ويصبح الرقم 10 لمن قام بعملية الحفظ أولاً

سؤالي هل يمكن الحفظ بمجرد تسجيل الإسم فقد يكون هناك خانات أخرى يجب تسجيلها ( أستخدم البرنامج للصادر وأقوم بتسجيل الأرقام الموجودة على النموذج مباشرة ولا يمكنني تغييرها فيما بعد عندما يتضح أن الرقم محجوز لمعاملة أخرى )

أرجو أن تكون ملاحظتي واضحة وأعتذر عن الإطالة

قام بنشر

السلام عليكم

الحقيقة تراودني فكرة حجز الرقم وكنت على عزم اقتراحها على أستاذنا محمد .. الفكرة وهي في رأسي الآن ليست صعبة وتطبيقها سهل إن شاء الله . ولكن يعيبها فيما لو تراجع المستخدم عن الحفظ وقد تعداه المسلسل فسوف تتكون عندنا أرقام شاغرة كثيرة .

بانتظار رد من الأخ محمد ولا يهون الجميع .

تحياتي .

قام بنشر

السلام عليكم

أخي أبو هادي ، أولا يا عم انت اللي أستاذنا :d

بالنسبة لموضوع المشاركة هنا :

هذا الموضوع يكاد يكون أكثر موضوع شغلني خلال اليومين الماضيين ، بالرغم من أني لم أكتب فيه

و قد جالت بخاطري أنا الآخر عدة خواطر ، منها فكرة الحجز

و منها أن دالة الاختبار لابد من أن تخبر المستخدم بأن الرقم سيتغير قبل تغييره

فأما الاولي فمن ضمن الافكار أنه بتراجع المستخدم يتم تسجيل الرقم الخالي فى جدول مؤقت و يتم السحب منه قبل استخدام الاضافة علي اكبر رقم متاح

و أما الثانية فأراها ضرورية لكي يعرف المستخدم بأي رقم حفظ السجل الذي أدخله

هذا من ناحية الاقتراحات

أما من ناحية النظرة العامة للموضوع ككل

فتوقفت معها ووصلت الي التالي :

احتياجنا لآلية الترقيم المتصاعد ( زيادة واحد علي آخر سجل ) و متي نحتاجها و نلجأ اليها دون الترقيم التلقائي

أولا عندما نريد أن يتاح لنا تعديل الارقام ، كأن نريد تغيير رقم مراسلة لاحقا ، و الترقيم التلقائي لا يسمح بالتعديل المباشر

ثانيا عندما يكون الترقيم له أسلوب خاص يسمح فيه بالتكرار عند اختلاف صفة أخري . مثلا بأن يكون هناك ترقيم متتالي لوارد كل شركة من الشركات ، سواء تم دمج هذا الترقيم مع نص ، أو ترك ترقيما مكررا مع اختلاف حقل آخر ، كالشركة مثلا

و المثال الاول ذو النموذج المنضم يفي بكل الاحتياجات و يعتبر آمن بعد الاختبار المتكرر الذي أضافه أبو هادي

و يمكننا أن نضيف عليه فقط عملية التنبيه بان الرقم تغير

و هو لا يحتاج الي عملية الحجز

اما الاضافة من نموذج غير منضم ، فهي التي ستحتاج الي الكثير من الحلول للتعامل معها ، مثل حل اضافة مصدر بيانات و ازالته ، و حل حجز الرقم

فهل هناك ميزة مقابلة ؟؟

بالطبع المحاولة فى حد ذاتها مفيدة ، و لكن هل نحن متفقون علي ان الحل الامثل للتعامل مع الترقيم المتصاعد هو الموذج المنضم؟؟

و اذا كان كذلك ، فهل هناك ميزة فى كون النموذج غير منضم ، لكي تشجعنا أكثر علي محاولة التغلب علي مشاكله

فى حالة التقيم التلقائي العادي ( مثلما فى الامثلى الثلاثة المشار اليها SQL,ADO,DAO فميزة النموذج الغير منضم هو عدم حجز السجل ) أما هنا فما الميزة ؟

مع تحياتي

قام بنشر

السلام عليكم

و المثال الاول ذو النموذج المنضم يفي بكل الاحتياجات و يعتبر آمن بعد الاختبار المتكرر الذي أضافه أبو هادي

و يمكننا أن نضيف عليه فقط عملية التنبيه بان الرقم تغير

و هو لا يحتاج الي عملية الحجز

نعم أخي محمد أنا أؤيدك كثيرا في هذا الرأي وأن عملية التنبيه بتغير الرقم كافي جدا .

و اذا كان كذلك ، فهل هناك ميزة فى كون النموذج غير منضم ، لكي تشجعنا أكثر علي محاولة التغلب علي مشاكله

أنا صراحة أحتاج إلى جواب من مستخدمي النماذج غير المنضمة ! ولم أكن أرغب في إبداء رأيي في هذا الموضوع لما رأيت كثير من المهتمين بالمبرمجة باستخدامها . فأنا أرى استخدام نموذج منضم بتحكم كامل متاح ولا أرى حتى بوجود أزرار للإضافة أو التعديل أو الحذف داعي لذلك ، إلا إذا كان تسيهلا للمستخدم ، ربما .

تحياتي .

قام بنشر

أعتقد أن السكوت علامة الرضا :)

و يبدو أن الأخوة موافقين علي هذا الرأي :)

أثناء تصفح الكود استوقفني سطر فيه ، وجدته جديد علي فارجو شرحه

    NullID = Nz(Me.id) = ""

علما بان NullID من نوع Boolean

و ماذا تعني ال 2 =

فارجو التوضيح

مع تحياتي

  • 3 weeks later...
قام بنشر

المثال :

و أعتقد أن النموذج الافضل فيه هو المنقول من الموضوع السابق للأخ أبو هادي ( رقم 2 )

و مرفق ال 4 نماذج 2 منضم + 2 غير منضم

و قد تم تعديل موضوع حجز الرقم فى النماذج المنضمة بستخدام sendkeys قبل الخروج

الأخ أبو يعلي : فى انتظار تجربتك و اختبارك للنماذج

مع تحياتي

Dmax.rar

  • Like 1
  • 2 weeks later...
قام بنشر (معدل)

السلام عليكم ورحمة الله وبركاته

أستاذي محمد طاهر :

سؤالي قمت بتجربة النتيجة التي توصلت لها مشكوراً من خلال النموذج المنضم الذي وضعه الأستاذ أبو هادي وكانت رائعه جداً في بداية التطبيق ولكن حدث ما كنت أخشاها إذ تكرر الرقم التلقائي ؟؟ بعد إستخدام البرنامج لفترة لم تتجاوز ثلاثة أيام مع العلم أنه تظهر الرسالة التي توضح حجز الرقم ولكن ربما الضغط على البرنامج من خلال أكثر من مستخدم في وقت واحد ( ستة مستخدمين ) أدى لنتيجة عكسية . هل يوجد حل لذلك وإذا لم يكن فما هو البديل . أتمنى أن أجد الإجابة والحل سريعاً إن شاء الله .

تم تعديل بواسطه امير عاطف
قام بنشر (معدل)

من المفترض أن نموذج الاخ ابو هادي به الاحتياطات الكافية ، فهل أنت متأكد من الكود فى برنامجك

فمبدأيا حاول مراجعة الكود فى برنامجك

و هل يمكن أن تجرب النموذج الاول ايضا ؟

تم تعديل بواسطه امير عاطف
قام بنشر

السلام عليكم

الأخ أبو يعلي .. البرنامج مصمم بشرط أن يكون الرقم المسلسل من خصائصه عدم قبول التكرار . فالمثال غير مسئول عن التكرار .

تحياتي .

قام بنشر

شكراً لك أستاذي محمد طاهر قمت بمراجعة الكود ولم أجد أي تغيير عن الكود الأساسي سوى المسميات الخاصة بالحقول وكان البرنامج في بدايته لا يسمح بالتكرار ولكن لا أعلم مالذي حدث بالضبط لم أقم بأي تعديل أوحذف في الكود . وعموماً سأعيد إختباره مرات ومرات فشكراً لك .

أستاذي أبو هادي إن كنت تقصد خصائص الحقل التلقائي في الجدول ( مفهرس بدون تكرار ) فهذا لا يمكن حيث سيتكرر الرقم في العام الجديد وإن كنت تقصد عدم التكرار في الكود فأنا لا أعلم أين هذه الخاصية بالضبط .

قام بنشر

السلام عليكم

هل تستخدم حقل تاريخ أو حقل رقمي للسنة ؟

عموما إذا كان ما تستخدمه حقل تاريخ فالموضوع يحتاج إلى إعادة نظر برمته :) .

وإذا كان حقل رقمي للسنة فيمكن عمل مفتاح للمسلسل والسنة معا .

تحياتي .

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

زائر
اضف رد علي هذا الموضوع....

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • تصفح هذا الموضوع مؤخراً   0 اعضاء متواجدين الان

    • لايوجد اعضاء مسجلون يتصفحون هذه الصفحه
×
×
  • اضف...

Important Information