Foksh

هذه ملاحظة تصميمية رائعة جداً . حيث توضح أن البيانات المتغيرة يجب تقسيمها إلى نوعين بناءً على طبيعتها :- 🔹 النوع الأول وهو بيانات متغيرة تحتاج إلى تحديث مستمر في الجدول الأساسي . مثل الرتبة ، الوظيفة ، مكان العمل ، المؤهل ... إلخ . ويتم الاحتفاظ بأحدث قيمة داخل جدول الموظفين الرئيسي ، ويتم تحديثها عند حدوث تغيير . كما يتم تسجيل جميع الحركات السابقة في جدول منفصل ، بحيث يمكن الرجوع إليها عند الحاجة . برأيي هذه النقطة مهمة لأن البحث والتصفية على جدول واحد يكون أسرع وأسهل . أيضاً عند البحث عن بيانات حديثة لكل الموظفين ، لن تحتاج إلى جلب جميع الحركات السابقة ، بل فقط أحدث حالة لكل موظف . ويمكن تطبيق هذه الفكرة على سبيل المثال في الجدول personal_data ، أضافة حقول مثل :- current_rank ( الرتبة الحالية ) ، current_job ( الوظيفة الحالية ) ، current_workplace ( مكان العمل الحالي ) ، latest_qualification ( آخر مؤهل ) . وفي جداول الحركات ( مثل الترقيات والتعديلات ) ، يتم تسجيل جميع الحركات السابقة ، وعند حدوث تغيير جديد يتم تحديث الحقل المناسب في جدول الموظفين الرئيسي . 🔹 النوع الثاني من البيانات وهو بيانات مستقلة بالكامل . مثل الإجازات ، التدريبات ، الجزاءات ، العقوبات ... إلخ ، فهذه البيانات متغيرة لكنها لا تؤثر على المعلومات الأساسية للموظف بشكل مباشر . لكن لكل منها جدول مستقل ويتم ربطه بـ rkm_mlf . أيضاً هذه نقطة مهمة لأن الموظف يمكن أن يكون لديه عدد غير محدود من الإجازات والتدريبات والجزاءات ... إلخ ، وبالتالي لا يُفضل إضافتها إلى الجدول الرئيسي للموظفين . وكما أن الفصل بين البيانات يجعل الاستعلامات أكثر كفاءة ودقة ، حيث يمكنك البحث عن الإجازات دون التأثير على بيانات الموظفين الآخرين . وأيضاً يمكن تطبيق هذه الفكرة على سبيل المثال بحيث يكون لكل نوع بيانات جدول مستقل ، مثل :- Leave_data ( جدول الإجازات ) ، Training_data ( جدول التدريبات ) ، Penalty_data ( جدول الجزاءات ) ، Promotion_data ( جدول الترقيات ) . 💥 أما فيما يخص التسميات الخاصة بحقل الربط بين الجداول وكما أشار أستاذي @ابوخليل ؛ فبدلاً من استخدام rkm_mlf في جميع الجداول ، يمكن تسميته بشكل متمايز كما يلي :- rkm_mlf في جدول personal_data ( جدول الموظفين الرئيسي ) rkm_mlf_func في جدول functional_data rkm_mlf_qual في جدول qualification_data

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

وعليكم السلام ورحمة الله وبركاته، بالنسبة لسؤالك حول وضع البيانات في جدول واحد أو توزيعها على عدة جداول ، فمن الأفضل استخدام 3 جداول منفصلة كما فعلت ( هذا بالنسبة لي طبعاً ) ، وذلك للأسباب التالية : 🔹 لماذا لا أفضل وضع البيانات في جدول واحد ؟؟؟ 1️⃣ تجنب تكرار البيانات :- إذا وضعت جميع البيانات في جدول واحد ، فقد تضطر إلى تكرار بيانات الموظف أكثر من مرة عند إضافة مؤهلاته أو تغيير بياناته الوظيفية . 2️⃣ تحسين الأداء وسهولة الاستعلامات :- الجداول الصغيرة تسهّل عمليات البحث والتحديث مقارنةً بجدول واحد ضخم يحتوي على بيانات مكررة . 3️⃣ التوسّع المستقبلي :- تقسيم البيانات يسهل إضافة ميزات جديدة مثل ترقيات الموظفين أو دورات تدريبية دون إعادة تصميم الجدول بالكامل . 🔹 ونقطة مهمة وهي كيف يتم الربط بين الجداول ؟؟؟ لضمان عمل الجداول بشكل صحيح ، يجب استخدام المفاتيح الأساسية (Primary Keys) والمفاتيح الأجنبية (Foreign Keys) كما يلي :- ✅ جدول البيانات الشخصية (Personal_data) :- اجعل rkm_mlf (رقم الملف) هو المفتاح الأساسي (Primary Key) ، لأنه فريد لكل موظف . ✅ جدول البيانات الوظيفية (Functional_data) :- أضف Functional_ID (ترقيم تلقائي) كمفتاح أساسي . استخدم rkm_mlf كمفتاح أجنبي (Foreign Key) لربطه بجدول البيانات الشخصية . ✅ جدول المؤهلات (Qualification_data) :- أضف Qualification_ID (ترقيم تلقائي) كمفتاح أساسي . استخدم rkm_mlf كمفتاح أجنبي (Foreign Key) لربطه بجدول البيانات الشخصية . هذا وقد أكون قد غفلت عن شيء ، فإن كنت قد سهوت فعل الأخوة والأساتذة يساندني ويذكرها 😇 .

وعليكم السلام ورحمة الله وبركاته ,, بدايةً من واجبي أن أنصحك بضرورة التقيد بسياسة وقوانين المنتدى من حيث :- 1. انتقاء العنوان المناسب والذي له دلالة على المشكلة . 2. الشرح الوافي والكافي للمشكلة . 3. ارفاق ملف للمشكلة لتتوضح للإخوة و الأساتذة اللذين يمروا في موضوعك . الآن بالنسبة للمشكلة ، فقد يكون هذا أحد عدة احتمالات ، منها :- 1. قد يكون النموذج الرئيسي يحتوي على نموذج فرعي يستخدم جدول ولنفترض Tbl_Customer وبنفس الوقت ان تحاول فتح نموذج آخر يستخدم نفس الجدول ، 2. قد يكون أيضاً مشكلة في قاعدة البيانات . هذا يعتمد على طريقة وبنية المشروع طبعاً

تفضل المرفق التالي .. 2025.accdb

انصحك بالإستعانة بصورة معبرة بدلاً من استخدام مربع النص الخاص الناتج عن ActiveX

تجسيداً لفكرة معلمنا الفاضل @ابوخليل ، اعتقد إنها الفكرة الأفضل عند تعدد العملات ،حيث من خلال الإستعلام تستطيع حصر السجلات بشرط نوع العملة . انقر زر نوع العملة لتغييرها هي مجرد فكرة ذات نتائج أفضل عند تراكم السجلات !! test (4).accdb

يوجد فكرة قديمة ، وأعتقد الأستاذ @Moosak له تجربة معها ، انظر فكرة الفيديو التالي :-

هل هذا ما تريده أخي العزيز @Ahmed_J ؟؟

أولاً تعديل الاستعلام بالشكل التالي :- SELECT DISTINCT basic.id2, Horizontal("basic","id2","namee",[basic].[id2]) AS name, Horizontal("basic","id2","school",basic.id2) AS school, Horizontal("basic","id2","work",basic.id2) AS [work], Horizontal("basic","id2","Committee",basic.id2) AS Committee, Horizontal("basic","id2","work_date",basic.id2) AS work_date FROM basic; والدالة في الوحدة النمطية بالشكل التالي :- Public Function Horizontal(tabelle As String, Feld1 As String, Feld2 As String, valFeld1, Optional sortField As String = "workdate") On Error GoTo ErrorHandler Dim DB As DAO.Database, rs As DAO.Recordset Dim sql As String Dim fieldName As String Dim isFirst As Boolean Set DB = CurrentDb sql = "SELECT [" & Feld2 & "] " & _ "FROM [" & tabelle & "] " & _ "WHERE ((([" & tabelle & "].[" & Feld1 & "])=" & valFeld1 & "))" Set rs = DB.OpenRecordset(sql) Horizontal = "" isFirst = True Do While Not rs.EOF If isFirst Then Horizontal = "*" & Nz(rs(Feld2), "") isFirst = False Else If Feld2 = "namee" Then Horizontal = Horizontal & vbCrLf & "" Else Horizontal = Horizontal & vbCrLf & Nz(rs(Feld2), "") End If End If rs.MoveNext Loop rs.Close Set rs = Nothing Set DB = Nothing Exit Function ErrorHandler: Horizontal = "" If Not rs Is Nothing Then rs.Close Set rs = Nothing End If Set DB = Nothing Exit Function End Function لاحظ أيضاً أنني قمت بتغيير أسماء حقلين في الجدول لعدم حدوث مشاكل في الكود أو الاستعلام 😅 . for send (0).accdb

وعليكم السلام ورحمة الله وبركاته ,, جرب التعديل التالي :- DoCmd.OpenForm "JO_IN_OUT", , , "[Ddate] = #" & Format(Me.ddate, "yyyy\/mm\/dd") & "#"

أخي الكريم ، برأيك هل الخطأ ( إنشاء استعلام في كل مرة يتم فيها النقر على الزر ) الموضح في الفيديو التالي منطقي بالنسبة لمبرمج 🤔 ؟؟؟؟؟؟

لا عليك ، ولكن قبل طرح الحل هنا . هل النتيجة التالية صحيحة ؟؟

ومن قال لك انها بلا مقابل ؟؟؟؟؟؟؟ صدقني جميعنا نبحث في حياتنا عن هذا المقابل 😇

حسناً ، لم تعجبني النتيجة السابقة بسبب تكرار الاسم في كل سجل ، لذا جرب هذا التعديل في الدالة :- Public Function Horizontal(tabelle As String, Feld1 As String, Feld2 As String, valFeld1, Optional sortField As String = "workdate") Dim DB As DAO.Database, rs As DAO.Recordset Dim sql As String Dim isFirst As Boolean Set DB = CurrentDb sql = "SELECT " & Feld2 & " FROM " & tabelle & " WHERE " & Feld1 & "=" & valFeld1 If sortField <> "" Then sql = sql & " ORDER BY " & sortField & " ASC" End If Set rs = DB.OpenRecordset(sql) Horizontal = "" isFirst = True Do While Not rs.EOF If Horizontal = "" Then Horizontal = "*" & rs(Feld2) Else If Feld2 = "name" Then Horizontal = Horizontal & vbCrLf & "" Else Horizontal = Horizontal & vbCrLf & rs(Feld2) End If End If rs.MoveNext Loop rs.Close Set rs = Nothing Set DB = Nothing End Function والإستعلام بعد التعديل :- SELECT basic.id2, Horizontal("basic","id2","name",[id2]) AS name, Horizontal("basic","id2","gov",[id2]) AS gov, Horizontal("basic","id2","workdate",[id2]) AS [work] FROM basic GROUP BY basic.id2; النتيجة :- المرفق الأخير الذي اعتمدته :- TEST22.accdb

حسناً ، جرب هذا التعديل في الدالة :- Public Function Horizontal(tabelle As String, Feld1 As String, Feld2 As String, valFeld1, Optional sortField As String = "workdate") Dim DB As DAO.Database, rs As DAO.Recordset Dim sql As String Set DB = CurrentDb sql = "SELECT " & Feld2 & " FROM " & tabelle & " WHERE " & Feld1 & "=" & valFeld1 If sortField <> "" Then sql = sql & " ORDER BY " & sortField & " ASC" End If Set rs = DB.OpenRecordset(sql) Horizontal = "" Do While Not rs.EOF If Horizontal = "" Then Horizontal = "*" & rs(Feld2) Else Horizontal = Horizontal & vbCrLf & rs(Feld2) End If rs.MoveNext Loop rs.Close Set rs = Nothing Set DB = Nothing End Function والإستعلام بعد التعديل :- SELECT basic.id2, Horizontal("basic","id2","name",[id2]) AS name, Horizontal("basic","id2","gov",[id2]) AS gov, Horizontal("basic","id2","workdate",[id2]) AS [work] FROM basic GROUP BY basic.id2; TEST22.accdb

لا عليك أخي الكريم ، هي فقط نصائح كي تحصل على النتائج المطلوبة بشكل أسرع لا غير 😀 . أيضاً استخدم تفعيل نبهني بالردود لتحصل على اشعار سريع عندما تكون في الموضوع . على العموم ، استبدل هذا السطر في الكود :- & " where " & Feld1 & "=" & valFeld1 & " order by " & Feld2 & " DESC ") بالسطر التالي فقط :- & " where " & Feld1 & "=" & valFeld1 & " order by " & Feld2 & " ASC ") وهو فقط تحويل الفرز من تنازلي DESC الى تصاعدي ASC . TEST22.accdb

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

متابع للإستفادة من خبرة معلمي الفاضل ابو خليل وكل عام وانتم بخير جميعاً

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

تفضل التعديل التالي :- SELECT Tbl_IN_OUT.ID, Tbl_IN_OUT.Nname, Tbl_IN_OUT.Start_Day, Tbl_IN_OUT.End_Day, Int(DateDiff('n',[Start_Day],[End_Day])/1440) & " يوم و" & Int((DateDiff('n',[Start_Day],[End_Day]) Mod 1440)/60) & " ساعات و" & DateDiff('n',[Start_Day],[End_Day]) Mod 60 & " دقائق و" & DateDiff('s',[Start_Day],[End_Day]) Mod 60 & " ثانية" AS [الفرق الزمني], Int(DateDiff('n',[Start_Day],[End_Day])/1440) AS الأيام, Int((DateDiff('s',[Start_Day],[End_Day]) Mod 86400)/3600) AS الساعات, Int((DateDiff('s',[Start_Day],[End_Day]) Mod 3600)/60) AS الدقائق, DateDiff('s',[Start_Day],[End_Day]) Mod 60 AS الثواني, Format(Int(DateDiff('s',[Start_Day],[End_Day])/3600), "00") & ":" & Format(Int((DateDiff('s',[Start_Day],[End_Day]) Mod 3600)/60), "00") AS [مجموع الساعات والدقائق] FROM Tbl_IN_OUT;

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

بالعكس أخي طاهر .. فرحتي تكتمل عند تجربتك المرفق والإفادة بنتائج جميع المشاكل التي واجهتها .

شهادة اعتز بها من أستاذ فاضل كأمثالك أخي @ابو عارف 😇 وأشكرك على إطرائك الرائع ، محاولتي في إيجاد الحل الذي يرضيني كانت بعد محاولات الفشل الذي جرتني في طريقها والعثرات التي كنت أدور في متاهتها , كنت أحوم سابقاً كما أسلفت حول أن المشكلة في كيفية قراءة التاريخ بالنسبة لتعدد واجهات أوفيس المختلفة إلى أن هداني الله إلى الدالة CLng لحل مشكلتي .. شكراً لك مرة أخرى وتقبل الله طاعاتكم وصالح أعمالكم ، وبعيدكم أسأل الله أن يهنأكم .

بعد تجربة الإقتراح الذي تم اختياره من قبل أستاذنا @أبوبسمله على عدة تنسيقات للتاريخ كانت النتيجة أنه لا يقوم بالمهمة المطلوبة عند اختلاف تنسيق التاريخ حسب النظام . المقترح التالي هو :- Dat = DateAdd("m", i, Me.Month_From) rst.FindFirst "[Payment_Month]=" & CLng(Dat) لماذا هذا الكود أدق ؟ يستخدم Date مباشرة دون تحويله إلى نص ، مما يضمن أن آكسيس يفهمه كتاريخ وليس كنص قد يسبب أخطاء CLng(Dat) يحول التاريخ إلى الرقم التسلسلي الداخلي الذي يخزنه آكسيس ، مما يزيل أي مشاكل تتعلق بالتنسيق لا يعتمد على إعدادات النظام ( سواءً كان mm/dd/yyyy أو dd/mm/yyyy ) ، لأن آكسيس يخزن التواريخ كأرقام وليس كنصوص لذا قمت بالبحث والتمحيص بأكثر من أسلوب وعدم اعتمادي للكود المقترح من طرف أستاذنا القدير أبو بسمله دون تجربة متعددة الخيارات ؟؟ لماذا الكود التالي أقل دقة ؟ Dat = Format(DateAdd("m", i, Me.Month_From), "yyyy-mm-dd") rst.FindFirst "[Payment_Month]=" & Format$(Dat, "\#mm\/dd\/yyyy\#") Format(DateAdd(...), "yyyy-mm-dd") يحوّل التاريخ إلى نص ، آكسيس لا يتعامل مع "yyyy-mm-dd" كتاريخ افتراضياً ، مما قد يؤدي إلى أخطاء عند البحث Format$(Dat, "\#mm\/dd\/yyyy\#") يحاول فرض التنسيق ، لكنه يعمل فقط إذا كانت الإعدادات الإقليمية للنظام متوافقة معه إذا كان النظام يستخدم dd/mm/yyyy ، فقد يفشل البحث بسبب اختلاف ترتيب اليوم والشهر يعتمد على إعدادات النظام ، مما قد يجعله غير متوقع في بعض الأجهزة 📌 النتيجة النهائية :- ✅ الكود الذي اقترحته حالياً (CLng(Dat)) أكثر دقة لأنه يعتمد على القيم الرقمية للتواريخ في آكسيس ❌ الكود المقترح سابقاً أقل موثوقية لأنه يعتمد على تحويل التاريخ إلى نص وقد يتأثر بإعدادات النظام 💥 وباختصار شديد :- استخدام CLng(Dat) أفضل لأنه :- يتعامل مع التاريخ كقيمة رقمية داخلية (Serial Date) يتجنب مشاكل تنسيق التاريخ المرتبطة بالإعدادات الإقليمية أكثر كفاءة في الأداء لأنه يقارن أرقام وليس نصوص يعكس طريقة تخزين آكسيس الفعلية للتواريخ داخلياً استخدام Format أقل دقة لأنه :- يحول التاريخ إلى نص (string) يعتمد على الإعدادات الإقليمية للنظام قد يسبب أخطاء عند اختلاف تنسيق التاريخ بين الأنظمة يحتاج إلى معالجة إضافية للتأكد من صحة التنسيق 📛 ملاحظة :- انا لا أبحث عن أفضل إجابة بقدر ما أبحث عن حل لمشكلة من جميع النواحي 😊 تأجيل الاقتطاع.zip