Foksh

النسخة 64 وعند تعديل قيمة الجداول ، تظهر الرسالة

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

النتيجة عندما تم فتح النموذج لأول مرة ، كان التاريخ 10-12-2025 وبعد النقر على الزر ، تحدث الليبل إلى تاريخ اليوم كما في الصورة :-

بعد الاطلاع على الملف المرفق المفتوح ، اعتقد أن اعتماد التاريخ والوقت كقيمة نصية هو ما يسبب هذه المشكلة .. فعند تعديل الدالة في المديول بهذا الشكل للتجربة .. Public Function vNow() As Date Dim currentTime As Date, currentdate As Date currentTime = Time() currentdate = Date vNow = currentdate + TimeValue(Format(currentTime, "hh:nn:ss")) End Function كانت النتيجة في النموذج :- السبب هو أن هذا الناتج سيكون عبارة عن نص كقيمة = 12/01/2025 14:33:20 اقصد انه ناتج عن الجزء التالي :- i = Format(currentTime, "HH:mm:ss") ii = Format(currentdate, "dd/mm/yyyy") vNow = ii & " " & i

اعتذر عن التأخر بالرد ، ولكن بسبب المباراة انشغلت مع بعض الزبائن في المحل على العموم ، أخشى أن اعطي نفسي كرت أصفر من التجارب حالياً ، لأن النتيجة غير سارة 😅 .. انظر

عندي نسختين أوفيس على كمبيوتري ، واحدة 2010 = 32 والثانية 2019 = 64

مستحي أعلّق 😇

لا اعلم صدقاً ..

للأسف انا لا استخدم أي برنامج باللغة العربية 😅 أكيد عندي النسخة المثبتة على أجهزتي ، وهذا الرابط .

عند فتح الملف على اوفيس 2010 = 32 بت ، تظهر الرسالة التالية :-

وعليكم السلام ورحمة الله وبركاته .. في الحقل نفسه داخل الجدول اجعل :- حجم الحقل = Double التنسيق = Fixed

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

وعليكم السلام ورحمة الله وبركاته .. الأصل في طلبك أن تقوم بتحديد اسم الجدول ، وأسماء الحقول فيه ونوعها ( رقمية أم نصية ) . وذكر اسماء مربعات النص في النموذج أيضاً . وستجد الحل الذي تريده . أو استخدم هذا التطبيق للأستاذ @Moosak في هذا الموضوع هنا :- الكاتب الذكي لدوال المجال وأيضاً تستطيع تعديل هذا السطر لما يتناسب مع مسميات حقولك وجدولك ومربعات النص :- =DLookup("Balance","Tbl_Stock","ItemID=" & Nz([ItemID],0) & " AND StoreID=" & Nz([StoreID],0))

بسيطة أخر الكريم .. في حدث بعد التحديث لمربع النص Payment الموجود في النموذج الفرعي Credit_Paper_Payments ، اجعل الحدث = Forms!credit_paper.CheckPaymentState جربه وأخبرني

وعليكم السلام ورحمة الله وبركاته .. من تجاربي لا يمكن عبر التنسيق الشرطي تغيير قيمة الكومبوبوكس فعلاً إلى (مدفوعة) ، ولذا توجهت إلى استخدام الفكرة التالية . استخدمت كود بسيط يقوم بمقام التنسيق الشرطي ، نضعه في النموذج الرئيسي :- Public Sub CheckPaymentState() If Nz(Me.Text63, "") = Nz(Me.Credit_Paper_Payments.Form.Text12, "") Then Me.Credit_Paper_Sub.Form!State = "مدفوعة" Else Me.Credit_Paper_Sub.Form!State = Null End If End Sub ونستدعيه أيضاً من النموذج الرئيسي في حدث في الحالي ، بهذا الشكل :- Private Sub Form_Current() Call CheckPaymentState End Sub طبعاً بما انني اعتمدت على قيمة مربع النص Text63 في النموذج الرئيسي مع قيمة مربع النص Text12 للمجموع في النموذج الفرعي Credit_Paper_Payments ، فاضطررت الى تعيين القيمة 0 له من خلال اضافة الدالة NZ له ليصبح مصدر بياناته = =Nz([Credit_Paper_Payments].[Form]![Text12],0) بدلاً من السابق :- =[Credit_Paper_Payments].[Form]![Text12] وبالتالي ملفك بعد التعديل :- server.zip

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

وعليكم السلام ورحمة الله وبركاته .. استخدم خاصية البحث في المنتدى أخي الكريم ، وستجد مواضيع تحدثت عن هذه الفكرة .. وأحدثها للأستاذ @منتصر الانسي في هذا الموضوع :-

🤨 لم تظهر المشكلة لدي أيضاً ، كما في الصورة المرفقة أعلاه . مع العلم أنه تم تجربة الرفق على إصدارين 2019 و 2010

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

ومنكم نتعلم ونستفيد 🤗 .. وخطر ببالي أيضاً نقطة صغيرة تتعلق بعدم صلاحية كود التفعيل بعد استخدامه . حاله حال رقم بطاقة التفعيل للجوال مثلاً ، يستعمل لمرة واحدة فقط (One-Time Use) .

دعنا نناقش الجوهر فقط . ففي النقطة السابقة المقتبسة ، إن كان خط سيرك بإضافة تاريخ داخل الأكواد ، فهي فعلاً معضلة وقد يكون الشخص الذي حمل النسخة بعد 25 يوم قد بقي لديه 5 أيام ( على افتراض ان النسخة التجريبية 30 يوم من تاريخ مدرج في الأكواد . لكن !!!! إن كانت المدة 30 يوم من تاريخ التشغيل الأول فهنا سيكون لكل مستخدم 30 يوماً كاملةً . وبالتالي ستستغني عن هذه العبارة التالية :- ستدخل في متاهة أن التفعيل هو للنسخة التجريبية أو للنسخة المفعلة الكاملة ( سنة على سبيل المثال ) ؟؟؟؟ بالتالي سيكون في ملف التفعيل المدمج أو الجدول رقمي تفعيل الأول للتجريبية والثاني عند التفعيل الكامل . ( إذا كان ما فهمته صحيحاً 😅 ) . تطرقنا سابقاً مع الأستاذ @ابو جودي في تجارب بهذا الخصوص ( فكرة التمديد ) . فلنفترض أنني كعميل أعجبني عملك ومشروعك ويخدمني بكل تفاصيله وقد اشتريت أو تم التفعيل لمدة 3 اشهر بعد الفترة التجريبية . وأردت قبل انقضاء مدة الـ 3 شهور هذه أن أقوم بتجديد الإشتراك مدة 3 شهور أخرى ، كتحليل :- الـ 3 شهور الأولى تنتهي بتاريخ 31-01-2026 ، وانا طلبت منك بتاريخ 10-01-2026 كود تفعيل لـ 3 شهور أخرى . أي سينتهي اشتراكي بتاريخ 30-04-2026 ( إن صحت حساباتي ) فهل التاريخ صحيح أم سيتم احتساب التمديد والتجديد من 10-01-2026 !!!!!! عادةً أفكر عند هذا العمل بأن يكون هناك معامل لعدد أيام التشغيل ( الفرق بين أول تشغيل أو تفعيل وتاريخ اليوم ، بحيث يكون العدد كأيام مطابق لفترة الإشتراك ) . وهنا ستكون الحاجة لأن يكون إجمالي عدد أيام منذ التفعيل الأول إلى نهاية الإشتراك = هذا العدد . أي ان في المثال السابق سيكون مجموع أيام الإشتراك أو تفعيل البرنامج = 90 يوماً وليس 70 يوماً . هذه الجزئية تعود لك كمبرمج ولآلية عملك التي تفضلها . ولكن انظر لها مستقبلاً . أفضّل بالنسبة لي أن يكون النموذج الخاص بالتمديد أو التفعيل هو نفسه الوحيد . وليس له داعي لتفعيل النسخة التجريبية . فيكفي أن يظهر لأول مرة للمستخدم أن البرنامج نسخة تجريبية مدتها 30 يوماً كرسالة . وسيكون هناك زر خاص بالتفعيل يفتح النموذج الوحيد هذا . ستختلف الأفكار وتترامى بين هنا وهناك ( وهذا ما وقعت فيه سابقاً ) وما دعاني لتجربة التفعيل الهوائي . فوجدت أنه محكم جداً إلى حد ما . ولا مانع لدي من مشاركتك الفكرة مفتوحة المصدر وشرحها إن تطلب الأمر 🤗 .

تمام يا صديقي ، للنظر في السطر حال وصولي للكمبيوتر .

وعليكم السلام ورحمة الله وبركاته .. وكما هو الحالي في جميع المواضيع التي طُرحت وتحدثت بهذا الخصوص ، وكان لكثير من الخبراء والمعلمين والأساتذة مشاركة - وأنت معلمي أحد أبرز هذه الشخصيات - حول أساليب وطرق تنفيذ هذه الخطوة في مشاريعهم التي تتعلق بقواعد بيانات آكسيس أو حتى بأي برنامج بلغة آخرى . وتلخصت جميع الحوارات على عدة نقاط وركائز أساسية منها باختصار :- طبيعة البصمة التي سيتم توليدها لكل جهاز ، وضمان عدم تكرارها عند عميل آخر . وطبعاً ستعتمد وكما هو معروف على عدة عوامل ومكونات لجهاز الكمبيوتر نفسه الذي سيعمل عليه البرنامج . رغم التحديات التي قد تواجه المطور ( المبرمج ) من حيث ، ماذا لو اختلفت قيمة أحد هذه العوامل التي يتكون منها معرف أو بصمة العميل ؟ لذا من الجيد والمهم إيجاد طريق مرن للتعامل مع هذه النقطة ( سبق أن تعاملت معها باعتماد 3 قيم من أصل 4 ) . فكرة النسخة التجريبية والتي كما ذكرتم أعلاه ، أن لها عدة أوجه للتعامل معها . حيث إما نسخة تعمل فقط لمدة محددة غير قابلة للتفعيل ( واجهة المشروع بدون الجداول حتماً ) ولاحظ أن ما بين قوسين سيكون بمثابة ثغرة وفجوة كبيرة . وإما أن تكون النسخة نفسها ذات المدة المحددة وبعد انتهائها تطلب من العميل التفعيل من خلال عدم عملها ؛ مع الأخذ بعين الإعتبار تلك الثغرات وعدم أخذ الحيطة لجميع الإحتمالات والسيناريوهات التي قد تحدث ، أو الأخذ بعين الإعتبار التلاعب بالتاريخ ( بما أن التفعيل والنسخة لا تعتمد على اتصال الإنترنت لضمان التاريخ الحقيقي عند تشغيل النسخة لأول مرة ... أو لاحقاً ) . عن تجربتي الشخصية وحيث أنني لا أشجع على أن تكون بصمة أو معرف العميل ظاهراً له ( قهراً وعناداً بأخصائيي الهندسة العكسية ) ، فقد توجهت لتنفيذ التفعيل من خلال الانترنت حصراً ؛ حالي كحال الشركات الكبيرة التي تعتمد على الإنترنت عند التفعيل . وهذا يجعل العميل محصوراً في خانة اليَّك أن برنامجه قد تفعل وأن مدة ونوع التفعيل ظاهراً له فقط لا غير بدون الكشف عن أي رقم يعرف عن جهازه . وهنا قد يكون وكما ذكرتم أن من حقه الحصول على مفتاح التفعيل الخاص بجهازه والإحتفاظ به بين يديه لاستعماله متى أراد . الإحتفاظ ببيانات التفعيل أو معلومات عن التفعيل داخل الجداول فقط قد تكون قابلة للحصول عليها أو الحقن أو غيرها من محاولات الإختراق . ليس المقصود أننا نتعامل مع بيانات آكسيس وليس معلومات عن البيت الأخضر أو الأبيض أو أي لون كان 😁 . ولكن بما أننا نتحدث عن الحماية فيجب الإلمام بجميع النواحي ( إلى حد ما ) . من المهم برأيي المتواضع إعلام المستخدم أن هذه النسخة تجريبية ومدتها س يوم . أو حتى على الأقل أن لا يتفاجئ المستخدم بأن النسخة التي تم تفعيلها لمدة عام مثلاً قد انتهت فجأة دون إشعاره بانتهاء مدة التفعيل . فيجب وضع إشعار قبل 15 يوم مثلاً من اقتراب انتهاء التفعيل . أما النسخة التجريبية فجيد أن يكون الإشعار ظاهراً دائماً في الواجهة الرئيسية . هذا ملخص ما خطر ببالي من أفكار قد تطرقتم لبعضها فيما سبق ، و وجهات النظر لا بد من أن تلتقي يوما ما . أما بخصوص الأسئلة التي طرحتها فمن خلال تجاربي وجدت أن التفعيل الـ Offline غير آمن وغير مجدي وغير مستقر . لذا توجهت إلى التفعيل الـ Online .