4.1HFSQL Client-Serveur: التثبيت والإدارة
الأساسي في 30 ثانية
- في وضع Client-Serveur يمركز خادم البيانات: التطبيقات ترسل إليه طلبات، وهو يعالجها ولا يعيد إلا النتائج — انخفاض هائل في حركة الشبكة، وأداء ومتانة مع تعدد المستخدمين، وأمان ووصول عن بُعد.
- خبر سار للترحيل: التحليل (ANALYSE) لا يتغير وكود WLangage يبقى متطابقًا إلى حد كبير (دوال H تعمل في الوضعين)؛ الجوهر في التثبيت وترحيل البيانات والاتصال.
- مفهومان أساسيان: المعاملات (الكل أو لا شيء) والأقفال (الوصول المتزامن)؛ ⚠️ خادم البيانات يتطلب إدارة حقيقية: مراقبة، تحديثات، والأهم نسخ احتياطي آلي ومُختبر.
حالة مصغّرة متسلسلة — ياسين ينقل تجارته إلى HFSQL Client-Serveur
ياسين، مطوّر WinDev في شركة صغيرة لتجارة المعدات الكهربائية في وهران، بنى تطبيق إدارة (عملاء، منتجات، طلبات، فواتير، مخزون). يعمل بنظام HFSQL Classic: ملفات البيانات موضوعة على مشاركة شبكة وكل جهاز يقرأها مباشرة. مع ستة مستخدمين (تجاريون، أمين مخزن، محاسب) يعملون في الوقت نفسه، ازداد البطء في ساعات الذروة، وانقطاع الشبكة أثناء إدخال طلب ترك مخزونًا مخصومًا دون طلب مقابل — تناقض صامت. قرر ياسين الانتقال إلى HFSQL Client-Serveur: يثبّت خادم HFSQL على جهاز مخصص، ويرحّل البيانات من Classic، وينشئ المستخدمين وحقوقهم على الخادم، ثم يضبط الاتصال في التطبيق. احتفظ بعادتين: تغليف عملية «الطلب + السطور + المخزون» في معاملة قصيرة (الكل أو لا شيء) وإدارة الأقفال بين المستخدمين. أخيرًا يضع نسخًا احتياطية آلية مخزّنة في مكان آخر ويختبر استعادة فعلية. ويسجّل المبدأ: التحليل لا يتغير، وكود H يبقى نفسه؛ العمل في التثبيت والترحيل والاتصال.
حالة مستقلة لهذا القسم: تعود في الدرس والمخطط والسكريبت وتحدي 48 ساعة للقسم 4.1.
1. خادم يمركز البيانات
الانتقال إلى HFSQL Client-Serveur يغيّر البنية. في Classic يقرأ كل جهاز ملفات البيانات مباشرة على القرص المحلي أو مشاركة الشبكة؛ وفي Client-Serveur يمركز خادم كل شيء: التطبيقات ترسل إليه طلبات، يعالجها ولا يعيد إلا النتائج. الفوائد كبيرة: حركة الشبكة تنهار (لا تمر إلا البيانات المفيدة)، ويتولى المحرك إدارة الوصول المتزامن، وينخفض خطر التلف بشدة، ويصبح الأمان ممكنًا (مصادقة، حقوق، تشفير)، ويصبح الوصول عن بُعد (العمل من المنزل، الفروع) سليمًا. أما الإدارة: مراقبة، ونسخ احتياطي بما في ذلك أثناء التشغيل، وصيانة مركزية.
2. التثبيت والترحيل والاتصال
عمليًا، يجب تثبيت الخادم وإدارته. (1) تثبيت خادم HFSQL على جهاز بأبعاد مناسبة (معالج، ذاكرة، قرص). (2) إنشاء قواعد البيانات وترحيل البيانات من Classic. (3) إدارة المستخدمين والحقوق على الخادم (من يقرأ، يكتب، يدير). (4) ضبط الاتصال في التطبيق (الخادم، المنفذ، بيانات الدخول). خبر سار للترحيل: بما أن التحليل لا يتغير وكود WLangage يبقى نفسه، يتركز الجوهر في هذه الخطوات.
3. المعاملات والأقفال
مفهومان يجب إتقانهما. المعاملات تضمن أن مجموعة كتابات تُنفّذ بالكامل أو لا تُنفّذ إطلاقًا: تسجيل طلب يعني إنشاء الترويسة والسطور وخصم المخزون وتحديث إجمالي العميل — إذا حدث انقطاع في المنتصف نحصل على طلب بلا سطور أو مخزون مخصوم بلا طلب. المعاملة تمنع هذه الحالة غير المتسقة الصامتة وتدير العزل بين المستخدمين. القفل يدير حالة قيام مستخدمين بتعديل السجل نفسه: منع التعديل المتزامن (تشاؤمي) أو كشف التعارض عند الحفظ (تفاؤلي) — والمهم ألا يُطمس تعديل بصمت («التحديث المفقود»). أبقِ المعاملات قصيرة: لا معاملة مفتوحة أثناء انتظار إدخال.
🔎 مثال ملموس — 🔎 مثال ملموس — الاتصال والمعاملة
هيكل تطبيق انتقل إلى Client-Serveur، مثل تطبيق ياسين:
// 1) Connexion au serveur HFSQL de la PME (Oran)
SI HOpenConnection("CnxNegoce", "srv-oran", "yacine", sMdp, hOuvre) = VRAI ALORS
HChangeConnection("*", "CnxNegoce")
SINON
Erreur("Serveur HFSQL injoignable : " + HErreurInfo())
FIN
// 2) Enregistrer une commande : TOUT OU RIEN
HTransaction("CnxNegoce")
SI HAjoute(Commande) ET HAjoute(LigneCommande) ALORS
HTransactionFin("CnxNegoce") // validé : tout est définitif
SINON
HTransactionAnnule("CnxNegoce") // annulé : rien n'est écrit
FINالقراءة: يُحدَّد الخادم باسمه ويصبح الاتصال المرجع لكل دوال H في التطبيق.
الدرس: المعاملة تغلّف العملية التجارية «الطلب + السطور + المخزون»: إما يُكتب كل شيء أو لا شيء — لا تناقض صامت أبدًا.
مفردات القسم
- بنية Client-Serveur
- خادم يمركز البيانات: التطبيقات ترسل إليه طلبات، يعالجها ولا يعيد إلا النتائج.
مثال بسيط: ياسين يثبّت خادم HFSQL لتجارته ذات الستة أجهزة.
ما ليس كذلك: وضع Classic حيث يقرأ كل جهاز الملفات مباشرة.
رد فعل: المركزة والموثوقية → Client-Serveur.
- الترحيل من Classic
- الانتقال إلى Client-Serveur: التحليل لا يتغير وكود WLangage يبقى متطابقًا إلى حد كبير — العمل في التثبيت وترحيل البيانات والاتصال.
مثال بسيط: ياسين يرحّل بياناته من Classic إلى الخادم دون تعديل تحليله.
ما ليس كذلك: إعادة كتابة كاملة للتطبيق.
رد فعل: تغيير البنية دون إعادة كتابة كل شيء → الترحيل.
- المعاملة
- ضمان تنفيذ مجموعة كتابات بالكامل أو عدم تنفيذها إطلاقًا (الطلب + السطور + المخزون، لا أحدها دون الآخر).
مثال بسيط: ياسين يغلّف إدخال الطلب في معاملة قصيرة.
ما ليس كذلك: أربع كتابات مستقلة، كل واحدة تُحفظ منفصلة.
رد فعل: عملية مركّبة → معاملة.
- القفل (الوصول المتزامن)
- آلية تدير حالة قيام مستخدمين بتعديل السجل نفسه، لتجنب أن يطمس تعديلٌ آخر بصمت.
مثال بسيط: ياسين يدير القفل بين مندوبين على بطاقة العميل نفسها.
ما ليس كذلك: ترك جهازين يكتبان دون رقابة (التحديث المفقود).
رد فعل: تجنب التحديث المفقود → القفل.
- الإدارة (⚠️)
- خادم البيانات يتطلب إدارة حقيقية: مراقبة، مستخدمون وحقوق، تحديثات، ونسخ احتياطي آلي ومُختبر.
مثال بسيط: ياسين يؤتمت نسخه الاحتياطي ويستعيد واحدة للتحقق.
ما ليس كذلك: «ثبّت وانسَ»، بلا مراقبة ولا نسخ احتياطي.
رد فعل: الخادم يُدار → الإدارة.
في التطبيق — تطبيقيًا — إعداد HFSQL Client-Serveur
- ثبّت خادم HFSQL على جهاز بأبعاد مناسبة، ثم أنشئ قاعدة البيانات ورحّل البيانات من وضع Classic، كما فعل ياسين.
- اضبط المستخدمين وحقوقهم على الخادم (قراءة، كتابة، إدارة)، ثم اضبط الاتصال في التطبيق.
- استخدم المعاملات للعمليات المركّبة من عدة كتابات مترابطة (الكل أو لا شيء)، وأدر الأقفال بين المستخدمين بشكل سليم.
- ضع نسخًا احتياطية آلية مخزّنة في مكان آخر، واختبر استعادة — نسخة احتياطية لم تُختبر لا قيمة لها.
سكريبت خطوة بخطوة — الانتقال إلى Client-Serveur كما فعل ياسين (5 دقائق)
1) ثبّت خادم HFSQL وحدّد أبعاده على جهاز مخصص. 2) أنشئ قاعدة البيانات ورحّل البيانات من Classic. 3) حدّد المستخدمين وحقوقهم على الخادم (قراءة، كتابة، إدارة). 4) اضبط الاتصال في التطبيق (الخادم، المنفذ، بيانات الدخول). 5) غلّف إدخال الطلب في معاملة قصيرة وتحقق من أن خطأً ما يلغي فعلاً كل الكتابات. 6) أتمت النسخ الاحتياطي، وخزّنه في مكان آخر، واختبر استعادة فعلية.
التحليل وكود H لا يتغيران: ركّز على التثبيت والترحيل والاتصال والإدارة (نسخ احتياطي مُختبر).
نموذج للنسخ واللصق — بطاقة Client-Serveur الخاصة بي
Classic : fichiers sur partage reseau, acces direct
Client/Serveur : serveur central, requetes -> resultats
Migration : analyse inchangee, code H identique
Connexion : serveur + port + identifiants (HOpenConnection)
Transactions : commande + lignes + stock = TOUT OU RIEN
Acces concurrents : gerer le BLOCAGE (eviter la MAJ perdue)
Administration : sauvegardes automatisees, stockees ailleurs ET TESTEESالانتقال Classic → C/S
ياسين يرحّل بيانات مشاركة الشبكة إلى خادم HFSQL مركزي.
معاملة قصيرة
ياسين يغلّف «الطلب + السطور + المخزون» في معاملة الكل أو لا شيء.
قفل مُدار
ياسين يمنع مندوبين من طمس بطاقة العميل نفسها أحدهما بالآخر.
نسخة احتياطية مُختبرة
ياسين يستعيد نسخة احتياطية على جهاز اختبار للتحقق من قابليتها للاستخدام.
✓ ممارسات جيدة
- الترحيل دون إعادة كتابة: التحليل وكود H لا يتغيران.
- إبقاء المعاملات قصيرة وإدارة أقفال الوصول المتزامن.
- أتمتة النسخ الاحتياطي واختبار استعادة واحدة.
✗ أخطاء شائعة
- الاعتقاد بأن الانتقال إلى C/S يفرض إعادة كتابة كل شيء.
- إبقاء Classic على مشاركة شبكة مع عدد كبير من المستخدمين.
- النسخ الاحتياطي دون اختبار الاستعادة أبدًا.
النقاط الأساسية
- في Client-Serveur يمركز خادم البيانات ولا يعيد إلا النتائج: أداء، متانة، أمان ووصول عن بُعد.
- الترحيل لا يغيّر التحليل ولا كود H: العمل في التثبيت والبيانات والاتصال.
- المعاملات (الكل أو لا شيء) والأقفال (الوصول المتزامن) تضمن الاتساق.
- ⚠️ الخادم يتطلب إدارة حقيقية: مراقبة، حقوق، تحديثات ونسخ احتياطي مُختبر.
تحدي 48 ساعة — طبّقه غدًا
كما فعل ياسين، أعدّ تقييمًا لتطبيقك: كم عدد المستخدمين المتزامنين، وما الأحجام، وما مظاهر البطء؟ إن ظهرت إشارة إلى ضرورة الانتقال، ثبّت خادم HFSQL للاختبار، ورحّل نسخة من البيانات واضبط الاتصال. ثم غلّف عملية مركّبة (طلب + سطور + مخزون) في معاملة قصيرة وأحدث خطأً للتحقق من عدم بقاء أي كتابة جزئية. أنهِ بـنسخة احتياطية مستعادة على جهاز اختبار.
- أعرف متى أنتقل من HFSQL Classic إلى Client-Serveur.
- أثبّت الخادم وأرحّل البيانات وأضبط الاتصال.
- أستخدم المعاملات والأقفال، مع نسخ احتياطي مُختبر.
أسئلة شائعة
متى يجب الانتقال من HFSQL Classic إلى HFSQL Client-Serveur؟
انتقل إلى Client-Serveur بمجرد أن يعمل عدة مستخدمين في الوقت نفسه وبكثافة (المعيار الأول)، أو عندما تكبر الأحجام، أو تحتاج إلى أمان دقيق أو وصول عن بُعد — ويبقى Classic ممتازًا في وضع جهاز واحد أو لعدد قليل من الأجهزة باستخدام خفيف. الإشارات: بطء متزايد في ساعات الذروة، حوادث تلف، حاجة إلى حقوق لكل مستخدم أو إلى تشفير، والعمل من المنزل. خبر سار للترحيل: التحليل لا يتغير وكود WLangage يبقى متطابقًا إلى حد كبير. نثبّت الخادم، ونرحّل البيانات، ونحدّث معاملات الاتصال.
لماذا المعاملات ضرورية مع تعدد المستخدمين؟
لأن العملية التجارية كثيرًا ما تتضمن عدة كتابات يجب أن تنجح معًا. تسجيل طلب يعني إنشاء الترويسة، وإنشاء السطور، وخصم المخزون، وتحديث إجمالي العميل: أربع كتابات لعملية واحدة. دون معاملة، يترك عطل أو انقطاع بعد الكتابة الثانية طلبًا بلا سطور أو مخزونًا مخصومًا بلا طلب — تناقض صامت يُكتشف بعد أسابيع. المعاملة تضمن الكل أو لا شيء: نفتحها، نكتب، ثم نحفظ أو نلغي. وهي تدير أيضًا العزل بين المستخدمين وتتشابك مع الأقفال.
لماذا المعاملات ضرورية في HFSQL مع تعدد المستخدمين؟