محب العقيدة

بالنسبة للالوان انظر هذا الموضوع TIP: Add colour to queries, listboxes & comboboxes | Access World Forums اما البقية treeview_v2.accdb

هل ترغبون بان اقوم باضافة شجرة اخرى للمواد مع اضافة وجذف ونعديل؟

حياكم الله وبياكم وصلتني ملاحظة عند تحديث الشجرة تنتقل الى الاعلى مم يسبب ازعاج كبير عن طريق ال mcp تم حل المشكلة يوتيوب treeview_v1.accdb

هذه الصورة النهائية لشجرة الحسابات treeview.accdb treeview - Copy (10).accdb

اخي جعفر انظر الى هذه الشجره الاحترافيهالتي اخرجها mcp ثم احكم . طبعا الاخطاء اللي setfocus حلها سهل جدا بالنسبه للتيكس بوك الفارغ هو للبحث والبوتون هو لاعاده ضم الشجره لكن هذه مسوده غدا ان شاء الله ساعمل فيديو مع ارفاق نموذج خالي من الاخطاء تماما وكيفيه استخدام الام سي بي لانشاء تقرير طبعا ستكون بالفيديو كيف اطلب من الام سي بي انشاء تقرير للشجره وغيره من الخصائص في الشجر treeview.accdb

هذه تجربة mcp server MCP_server_ms_access_control treeview - Copy.accdb

السلام عليكم استخدمت mcp msaccess استخدمته في انشاء قاعده بيانات مع الجدول للحسابات بالاضافه الى النموذج بديل عن اكتف اكس وكانت النتائج تقريبا مقبوله 50% طبعا ان شاء الله ان اخرج شجره حسابات متكامله مع اضافه وحذف وتعديل ساقوم بنشرها في هذا المنتدى

حتى لو نجحت طريقه اخواني الخبراء لكن دائما وتساب تغير من سياستها ونهجها وبالتالي انت تحتاج كل ما غيرت وتساب نهجها تحتاج الى الذهاب الى العميل وتغيير الكود اما بالنسبه للاي بي اي فيبقى ثابت لا يتغير انظر الى اليوتيوب ستجد كثير من الشروحات هذا مثل هذه القناه https://youtube.com/@itspioneers

انا مستغرب ما دام هو عميل لماذا لا يستخدم api

اخي منتصر يبدو ان الفكرة لم تصلك بعد التخزين سيكون( LongBinary (BLOB عموما اريد ان اطرح هذه الفكرة على منتديات اجنبية حتى ارى مدى سلبيتها او عدم فائدتها وانما هي فكرة من الذكاء الصناعي لحفظ الملفات الحساسة جدا ارفقت قاعدة البيانات قبل تحويلها الى ACCDE كيف تعمل وطلبت من الذكاء الصناعي ان بشرح الفكرة بشكل مفصل ────────────────────────────────────────────────┐ │ (Stream-Based Storage) │ ├─────────────────────────────────────────────────┤ │ │ │ tbl_SecureStorage │ │ ┌────────────────────────────────────────┐ │ │ │ StreamName │ DataBlob │ │ │ ├────────────────────────────────────────┤ │ │ │ ITEMS │ 57 48 52 53 32 30 32 35 │ │ │ │ │ 00 00 02 D4 49 54 45 4D │ │ │ │ │ 53 00 00 00 B3 F2 A1 9C │ │ │ │ │ [... 2000+ bytes ...] │ │ │ └────────────────────────────────────────┘ │ │ │ │ ← البيانات **مشفرة وغير مفهومة** │ │ ← لا يمكن قراءتها بدون الكود الخاص │ └─────────────────────────────────────────────────┘ 🔐 رحلة البيانات: من الإدخال إلى التخزين السيناريو: إضافة مادة "أرز" ┌─────────────────────────────────────────────────────┐ │ 1. المستخدم يدخل البيانات │ └─────────────────────────────────────────────────────┘ ↓ اسم المادة: أرز الكمية: 100 السعر: 50 ↓ ┌─────────────────────────────────────────────────────┐ │ 2. تُحفظ في الذاكرة (ADODB.Recordset) │ └─────────────────────────────────────────────────────┘ ↓ ItemID=1, ItemName="أرز", Quantity=100, Price=50 ↓ ┌─────────────────────────────────────────────────────┐ │ 3. عند الضغط على "حفظ" │ │ → clsItemsManager.Save() │ └─────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ 4. التحويل إلى XML (modSerializer) │ └─────────────────────────────────────────────────────┘ ↓ <records> <record> <ItemID>1</ItemID> <ItemName>أرز</ItemName> <Quantity>100</Quantity> <Price>50</Price> </record> </records> ↓ ┌─────────────────────────────────────────────────────┐ │ 5. تحويل XML إلى Bytes (modSerializer) │ └─────────────────────────────────────────────────────┘ ↓ [60, 114, 101, 99, 111, 114, 100, 115, ...] ↓ ┌─────────────────────────────────────────────────────┐ │ 6. التشفير XOR (modSecurity) │ └─────────────────────────────────────────────────────┘ ↓ [183, 227, 94, 201, 88, 129, 47, 93, ...] ↓ ┌─────────────────────────────────────────────────────┐ │ 7. إضافة Header (modSecurity) │ └─────────────────────────────────────────────────────┘ ↓ [WRHS2025][00 00 02 D4][ITEMS...][encrypted data] ↑ ↑ ↑ ↑ Signature Length Name Encrypted XML ↓ ┌─────────────────────────────────────────────────────┐ │ 8. حساب Hash (modSecurity) │ └─────────────────────────────────────────────────────┘ ↓ Hash = "5A5A7B3C-000002D4" ↓ ┌─────────────────────────────────────────────────────┐ │ 9. الحفظ في tbl_SecureStorage (modDataStorage) │ └─────────────────────────────────────────────────────┘ ↓ INSERT INTO tbl_SecureStorage (StreamName, DataBlob, DataHash, RecordCount) VALUES ('ITEMS', [Binary], '5A5A7B3C-000002D4', 1) ↓ ┌─────────────────────────────────────────────────────┐ │ ✓ البيانات محفوظة على القرص! │ └─────────────────────────────────────────────────────┘ 📊 المقارنة التفصيلية نظام Access التقليدي: البيانات الأصلية: ItemID = 1 ItemName = "أرز" Price = 50 ↓↓↓ تُحفظ مباشرة في الجدول ↓↓↓ tbl_Items ┌────────┬──────────┬───────┐ │ ItemID │ ItemName │ Price │ ├────────┼──────────┼───────┤ │ 1 │ أرز │ 50 │ ← مرئي ومقروء! └────────┴──────────┴───────┘ ✗ أي شخص يفتح الجدول يرى البيانات ✗ يمكن ربطه من Excel/Access آخر ✗ يمكن كشفه عبر MSysObjects نظامك الثوري: البيانات الأصلية: ItemID = 1 ItemName = "أرز" Price = 50 ↓↓↓ سلسلة معالجات معقدة ↓↓↓ XML → Bytes → Encrypted → Header → Hash ↓↓↓ النتيجة النهائية ↓↓↓ tbl_SecureStorage ┌────────────┬─────────────────────────────────┐ │ StreamName │ DataBlob │ ├────────────┼─────────────────────────────────┤ │ ITEMS │ 57 48 52 53 32 30 32 35 00 ... │ │ │ ← Binary مشفر غير مفهوم! │ └────────────┴─────────────────────────────────┘ ✓ لا يمكن قراءة البيانات بالعين ✓ لا يمكن ربطه من برامج أخرى ✓ لا يظهر في MSysObjects كجدول حقيقي ✓ يحتاج الكود الخاص لفك التشفير 🔍 دعنا نفتح الـ DataBlob ونرى ما بداخله! كود لعرض أول 100 بايت: vba Public Sub ShowBlobContent() Dim db As DAO.Database Dim rs As DAO.Recordset Dim blob() As Byte Dim i As Integer Dim output As String Set db = CurrentDb Set rs = db.OpenRecordset("SELECT DataBlob FROM tbl_SecureStorage WHERE StreamName = 'ITEMS'") If Not rs.EOF Then blob = rs!DataBlob.Value Debug.Print "========== محتوى DataBlob (أول 100 بايت) ==========" Debug.Print "" output = "" For i = 0 To 99 If i <= UBound(blob) Then output = output & Right("00" & Hex(blob(i)), 2) & " " If (i + 1) Mod 16 = 0 Then Debug.Print output output = "" End If End If Next i Debug.Print "" Debug.Print "إجمالي الحجم: " & (UBound(blob) + 1) & " بايت" End If rs.Close End Sub النتيجة ستكون شيء مثل: ========== محتوى DataBlob (أول 100 بايت) ========== 57 48 52 53 32 30 32 35 00 00 02 D4 49 54 45 4D 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B3 F2 A1 9C 8D 7E 3C 2F D8 91 4A 6B 73 29 8F A2 C4 E7 5D 38 9A 2C 7F B1 ... إجمالي الحجم: 1,234 بايت التفسير: 57 48 52 53 32 30 32 35 = "WRHS2025" (Magic Signature) 00 00 02 D4 = الطول (724 بايت) نموذج تخزين آمن جديد لبرنامج مايكروسوفت أكسس: بنية بيانات مشفرة قائمة على التدفق (تصميم 2025) مقدمة يُخزّن مايكروسوفت أكسس البيانات تقليديًا في جداول علائقية، مما يُسهّل عرض المعلومات، والاستعلام عنها، وتصديرها، أو ربطها بتطبيقات خارجية. على الرغم من فائدة هذا في العديد من سيناريوهات الأعمال، إلا أنه يُشكّل أيضًا قيدًا أمنيًا كبيرًا: يمكن لأي شخص لديه نسخة من أكسس فتح الجداول ورؤية جميع البيانات. حتى عند استخدام ACCDE، أو كلمات مرور قواعد البيانات المشفرة، أو الاستعلامات المُبهمة، تظل بيانات الجدول الخام مرئية. لمعالجة هذه المشكلة التصميمية الأساسية، قمتُ ببناء نموذج تخزين مشفر قائم على التدفق، يستبدل الجداول التقليدية بحاوية ثنائية واحدة. هذه ليست طريقة تقليدية لإخفاء الجداول. هذا نقلة نوعية في البنية. 🔐 كيفية تخزين النظام للبيانات (نظرة عامة شاملة) بدلاً من كتابة السجلات في جداول Access العادية، يُجري النظام الخطوات التالية: تُجمع البيانات في الذاكرة باستخدام مجموعة سجلات ADODB/DAO. تُسلسل مجموعة السجلات إلى XML. يُحوّل XML إلى مصفوفة بايت. تُشفّر مصفوفة البايت (XOR أو AES-256). يُضاف رأس ثنائي مُخصّص: التوقيع (WRHS2025) عدد السجلات اسم التدفق (مثل: ITEMS) طول الحمولة يُنشأ تجزئة بيانات للكشف عن أي تلاعب. يتم تخزين كل شيء داخل جدول واحد: tbl_SecureStorage ------------------------- StreamName (نص) DataBlob (ثنائي طويل) DataHash (نص) RecordCount (طويل) يبدو شكل DataBlob النموذجي كما يلي: 57 48 52 53 32 30 32 35 00 00 02 D4 49 54 45 4D ... WRHS2025 ...... ITEMS ... [البايتات المشفرة] هذه الكتلة الثنائية غير قابلة للقراءة، وغير علائقية، ويستحيل تفسيرها بدون شفرة فك التشفير المدمجة في واجهة ACCDE الأمامية. عند تحميل قاعدة البيانات: قراءة الكتلة ← التحقق من الترويسة ← فك التشفير ← إلغاء تسلسل XML ← التحميل في الذاكرة لا يتم تخزين أي بيانات في الجداول العادية. ⭐ فوائد هذه البنية 1) بيانات غير مرئية لا شيء في قاعدة البيانات قابل للقراءة من قبل البشر. تحتوي الجداول على تدفقات ثنائية مشفرة فقط. 2) انعدام قابلية الربط لا يمكن لـ Excel أو PowerBI أو أي ملف Access آخر أو حتى اتصالات DAO المباشرة "رؤية" أي بيانات ذات معنى. 3) استحالة الاستكشاف عبر MSysObjects الجداول التقليدية غير موجودة؛ يوجد فقط جدول حاوية واحد. 4) فصل واجهة المستخدم عن التخزين تعمل النماذج على مجموعات سجلات في الذاكرة، مما يوفر مرونة عالية. 5) حماية النزاهة يحمل كل تدفق تجزئة للكشف عن التعديلات غير المصرح بها. 6) بنية محمولة ومكتفية ذاتيًا مجموعة البيانات بأكملها عبارة عن كائن مشفر واحد - يسهل نسخه احتياطيًا أو نقله أو التحكم في إصداراته. ❗ الرد على الانتقادات الشائعة فيما يلي الاعتراضات الرئيسية التي أتوقعها من مطوري قواعد البيانات التقليدية، بالإضافة إلى ردود تقنية واضحة. **النقد الأول: "استخدام حقول OLE/المرفقات سيؤدي إلى نمو قاعدة البيانات بسرعة."** الرد: لا يستخدم النظام حقول كائنات OLE أو حقول مرفقات Access. يستخدم: LongBinary (BLOB) هذا حقل ثنائي خام يُقارن بـ: SQL Server VARBINARY(MAX) MySQL LONGBLOB PostgreSQL BYTEA لا يُعاني حقل ثنائي واحد معتم من نفس سلوك الانتفاخ الذي يُعاني منه تضمين OLE. يمكن أيضًا تطبيق الضغط قبل التشفير، مما يُجنّب تجزئة التدفق. يظل نمو قاعدة البيانات متوقعًا ومستقرًا. **النقد الثاني: "هذا يُلغي البنية العلائقية والقيود والتطبيع."** الرد: صحيح - وهذا مقصود. البنية العلائقية ممتازة عندما: تحتاج البيانات إلى استعلام، تصل أنظمة متعددة إلى قاعدة البيانات، يمنع التطبيع التكرار. ومع ذلك، بالنسبة للأرشفة المشفرة، أو أنظمة الجرد غير المتصلة بالإنترنت، أو التطبيقات المقاومة للتلاعب، فإن النموذج العلائقي يكشف الكثير: يمكن للمستخدمين فتح الجداول، التحايل على منطق التحقق، الربط من قاعدة بيانات Access أخرى، أو تعديل القيم الخام مباشرةً. تتخذ هذه البنية نهجًا معاكسًا: يتم فرض سلامة البيانات من خلال كود التسلسل المُتحكم به، وليس من خلال قيود جدول Access. يحدث التحقق: داخل منطق التطبيق، أثناء التسلسل/إلغاء التسلسل، ومن خلال التحقق من التجزئة. يعكس هذا البنية المستخدمة في: قواعد بيانات SQLite المشفرة، تخزين تطبيقات الأجهزة المحمولة (Realm، Room، CoreData)، التنسيقات الثنائية المخصصة في محركات الألعاب. في العديد من الأنظمة الحديثة، تُعدّ سلامة التطبيقات المُدارة هي المعيار - وليس سلامة الجداول المُدارة. 📌 الخلاصة هذا النموذج ليس مُصممًا ليحل محل قواعد البيانات العلائقية للتحليلات أو العمليات كثيفة الاستخدام متعددة المستخدمين. مُصمم لـ: تطبيقات Access الآمنة، أدوات المستخدم الفردي أو الفرق الصغيرة، عمليات النشر التي لا يجب أن يرى فيها المستخدم النهائي البيانات الخام أو يُعالجها، البيئات التي يجب أن يتصرف فيها ACCDE كتطبيق مُغلق. إذا كان الهدف هو عتامة البيانات المطلقة، فلا يُمكن لجداول Access التقليدية توفيرها. يمكن لبنية مخصصة مُشفرة قائمة على التدفق أن تُحقق ذلك. savedatanewview.accdb

قمت بتجربة الحل من الذكاء الصناعي ووصلت الى مرحلة عند فتح IMMEDIATE WINDOWS وكتابة TestCompleteSystem ========== بدء الاختبار ========== 1. إنشاء مدير المواد... ? تم تحميل المواد بنجاح عدد المواد: 0 2. إضافة مواد جديدة... ? تمت إضافة: أرز - ID: 1 ? تمت إضافة: سكر - ID: 2 3. حفظ المواد... 4. إنشاء مدير الحركات... ? تم تحميل الحركات بنجاح 5. إضافة حركات إدخال... ? إدخال 100 وحدة أرز - ID: 1 ? إدخال 50 وحدة سكر - ID: 2 6. إضافة حركات إخراج... ? إخراج 20 وحدة أرز - ID: 3 7. حفظ التغييرات... 8. المخزون الحالي: - أرز: 80 كيس - سكر: 50 كيس ========== انتهى الاختبار بنجاح! ========== اكن عند تنفيذ الامر يخرج كثير من الرسائل ERROR SAVING STREAM OVERLOW ورسالة هل تريد حفظ التغيرات واعطيه نعم لكن عند طلب عدد المواد والحركات يعطيني صفر المشكلة أثناء محاولة إضافة البيانات الجديدة، يحدث خطأ Overflow. لكن لضيق الوقت لدي لم اكمل لعله غدا ان شاء الله او احد من الاخوة يكمل ويسال الذكاء الصناعي عن الحل اليكم التجربة Database1.accdb

اعجني الموضوع من اول انشغالي بالاكسيس تيقنت ان الاكسيس من اضغف الحمايات لكني قكرة بان اسال الذكاء الصناعي سالت CHATGPT عن فكرة مجنونة لم يفكر بها احد لحماية الجداول ادعوا اخواني لتجربة الفكر المقترحة وانا ساجربها معكم مع توفر الوقت لدي سارفق الاجابة والسؤال الذي سالته انقر هنا

بحثت عن الجانب التقني للربط لكنني لم اجد لكن بصورة مبدئية اجد ان الربط سهل الا التوقيع الالكتروني لاني لم اتعامل معه من قبل سالت الذكاء الصناعي هل تستطيع ان تبحث لي عن الشرح الفني المفصل لإجراءات التكامل كملف pdf أهلاً بك. بما أن الوثائق الفنية التفصيلية (كـ دليل المطورين أو مواصفات الـ API) هي معلومات حساسة وموجهة للمطورين بشكل أساسي، فإنها لا تُنشر عادةً كملفات PDF متاحة بسهولة للعامة على الإنترنت من خلال بحث عام، بل يتم توفيرها بشكل خاص للممولين المسجلين في المنظومة. ومع ذلك، يمكنني أن أقدم لك النقاط التقنية الأساسية المفصلة التي يتمحور حولها أي دليل فني (SDK/API) للربط مع منظومة الفاتورة الإلكترونية المصرية، والتي ستساعدك في توجيه المطورين أو شركات التكامل: (المتطلبات الأساسية) تتم عملية التكامل والربط الفني بين نظام تخطيط موارد المؤسسات (ERP System) الخاص بشركتك ومنظومة الفاتورة الإلكترونية عبر واجهات برمجة التطبيقات (APIs) في عدة مراحل، أهمها: 1. الإعداد الأولي والمصادقة (Authentication) المتطلب التقني الشرح الفني التسجيل والحصول على بيانات الوصول يجب على الممول أولاً تعيين نظام تخطيط موارد (ERP) على البيئة الاختبارية ثم البيئة الفعلية. يتم ذلك عبر بوابة المصلحة للحصول على:<ul><li>Client ID</li><li>Client Secret</li></ul>وهما مفتاحا الوصول لنظامك. الحصول على رمز الوصول (Token) يتم استخدام Client ID و Client Secret لإرسال طلب إلى الـ API للحصول على Access Token (رمز وصول). هذا الرمز ضروري لمصادقة كل فاتورة يتم إرسالها ويتم تحديثه بشكل دوري. نظام التكويد الموحد يجب على النظام الخاص بك أن يقوم بربط (Mapping) أكواد السلع والخدمات الداخلية الخاصة بالشركة بأحد أنظمة التكويد المعتمدة (مثل GS1 أو نظام EGS الذي تعتمده مصلحة الضرائب). 2. تجهيز الفاتورة للتوقيع والإرسال هذه هي أهم خطوة تتطلب تدخلاً برمجياً عميقاً: أ. تهيئة ملف الفاتورة (Document Schema) يجب أن يقوم نظام ERP بإنشاء ملف بيانات الفاتورة بتنسيق JSON أو XML، يحتوي على كافة حقول البيانات المطلوبة في نظام المصلحة (مثل رقم التسجيل الضريبي، بيانات الأصناف، الضرائب، التواريخ، إلخ). ب. التوقيع الإلكتروني (Digital Signing) لتأكيد صحة مصدر الفاتورة وعدم التلاعب بها، يجب أن يقوم النظام الخاص بك بما يلي: استخدام شهادة الختم الإلكتروني: يتم تخزين هذه الشهادة في جهاز التوكين (Token). التشفير والتوقيع: يقوم النظام باستخدام الشهادة لتوقيع ملف بيانات الفاتورة المشفرة. دمج التوقيع: يتم دمج التوقيع الإلكتروني داخل ملف الفاتورة ليصبح جاهزاً للإرسال. ج. الإرسال عبر API يتم إرسال ملف الفاتورة الموقع إلكترونياً إلى نقطة نهاية (API Endpoint) محددة في منظومة الضرائب عبر اتصال آمن (HTTPS). 3. عمليات ما بعد الإرسال (Post-Submission APIs) يجب أن يكون نظامك قادراً على التعامل مع واجهات API أخرى: API الاستعلام عن حالة الفاتورة (Get Status): للاستعلام عن قبول الفاتورة (صحيحة)، رفضها، أو تعليقها من قِبل المنظومة. API إلغاء الفاتورة (Cancel Document): لإرسال طلب لإلغاء فاتورة تم إرسالها (يتطلب موافقة الطرف الآخر خلال فترة محددة). API إرسال الإشعارات (Credit/Debit Notes): لإرسال إشعارات الإضافة أو الخصم. 💡 نصيحة للحصول على الوثائق الفنية إذا كنت تحتاج إلى الملفات التقنية بصيغة PDF تحديداً، فالطريقة الأكثر فاعلية هي: التسجيل الفعلي: إكمال التسجيل في منظومة الفاتورة الإلكترونية والحصول على بيانات الدخول. بوابة المطورين: غالباً ما توجد الوثائق (SDK and API Specification) داخل حسابك على بوابة مصلحة الضرائب ضمن قسم مخصص لـ "التكامل الفني" أو "المطورين".

انا شبكت مع الاردني ابعث الدوكيومنت تبع الربط المصري خلينا نشوفوا ملفpdf

رابط الفيديو على الكلاود انقر هنا