להעביר את Paradox ו-BDE בצורה מבוקרת ל-MariaDB

רוב היישומים התוכניים של Delphi נבנו עם טבלאות Paradox ועם Borland Database Engine (BDE), כי זה היה אז תקן פרגמטי: מקומי, מהיר להתנעה, ודורש מעט תשתית. בפועל מערכות אלה פועלות לעתים קרובות עד היום בסביבת ייצור — כולל דיווחים, הדפסת תוויות, ייבוא/ייצוא, עבודות אצווה, טבלאות היסטוריה ולוגיקה ייחודית שנכנסה לגישת הנתונים לאורך השנים. לכן הגירה אינה רק ייצוא נתונים, אלא שיפוץ מבוקר: מודל נתונים, התנהגות SQL, תופעות לוואי בקוד ותהליכי תפעול צריכים להיבדק יחד.

MariaDB היא לעתים קרובות יעד טוב כאשר דרושים: פעולת משתמשים מרובים יציבה, טרנזקציות נקיות, גיבויים מרכזיים, שכפול, ניהול הרשאות ברור ויכולת חיבור לפורטלים ווב, שירותים או REST-APIs. האתגר אינו בדרך כלל בהתקנת מסד הנתונים — המאמצים העיקריים הם בשביל מסלול הגירה בטוח: כיצד מועברות טבלאות, אינדקסים, מפתחות ראשיים, מערכות תווים, שדות תאריכים, ערכים „ריקים“ וקשרים רפרנציאליים בצורה נכונה מבלי לשבור את הלוגיקה התוכנית בשעת ריצה?

מאמר זה מתאר גישת עבודה מבוססת להיגררת Paradox ו-BDE ל-MariaDB באופן מבוקר: מבוסס טכנית, בשלבים ובמוקד על יציבות. המטרה היא בסיס איתן לשלביה הבאים של המודרניזציה — לדוגמה החלפת BDE, מעבר ל-BDE-Ablösung mit nativer Anbindung, ארכיטקטורת Layer-3 ברורה, REST-Server ולקוחות רב-פלטפורמיים.

למה הגירה מ-Paradox/BDE היא יותר מהחלפת מסד נתונים

Paradox כפורמט קבצים ו-BDE כשכבת גישה מהווים מערכת משולבת עם תכונות ייחודיות שאינן נדרשות או רצויות לשחזור 1:1 ב-MariaDB. תסמינים טיפוסיים בשימוש היום-יומי הם:

• תלויות לא שקופות: משפטי SQL מפוזרים (Forms, DataModules, Reports, ביטויי SQL דינמיים), לעתים ללא ממשל מרכזי.
• התנהגות „על הרגש“: מסננים, מיון או joins מסוימים עובדים במקרה כי Paradox/BDE סובלני או מבצע המרות טיפוס סמיות.
• מגבלות מרובת משתמשים: נעילות מבוססות קבצים, נפילות ביצועים ברשת, בעיות locking עם צמיחת נפח הנתונים.
• סיכוני תחזוקה: תלות ב-BDE, דרייברים ישנים, פריסת גרסאות מודרניות של Windows בעייתית, נושאי 64‑Bit/ARM64.

הגירה מבוקרת אינה מתייחסת לפריטים אלה כהשפעות לוואי, אלא כקריטריונים של מטרה. MariaDB אינה רק „מסד נתונים חדש“ אלא הזדמנות לפירוק שכבת גישת הנתונים, הגברת שלמות העסקית ואפשרות חיבורית מוגדרת לממשקים.

תמונה רצויה: MariaDB כבסיס נתונים יציב לשולחן העבודה, שירותים ופורטלים

תמונה רצויה עבור יישומי B2B מורכבת לרוב משלוש שכבות:

• מסד נתונים (MariaDB): אחסון נתונים עקבי, אינדקסים, Constraints, טרנזקציות, משתמשים/תפקידי גישה, גיבויים.
• לוגיקה מקצועית (Server/Services): ולידציות, Workflows, Importer, Scheduler, ממשקי חיבור. אופציונלי כ-REST-Server, Windows- או Linux-Services.
• לקוחות (VCL/FMX/Web): ממשקי משתמש, דוחות, חלקים אופליין, אינטגרציות. אידיאלית עם חוזים ברורים מול הלוגיקה המקצועית.

תלוי במצב ההתחלתי לא צריך ליישם הכל מיד. עם זאת ההגירה צריכה להיות מתוכננת כך שלא תחסום את המעבר לארכיטקטורה נקייה. מי שמעתיק היום טבלאות בלבד ומחר ממשיך „לצרוב“ מכל טופס גישה ישירה למסד הנתונים — אמנם הכניס MariaDB, אך הסיכונים המהותיים נשארים.

מלאי: מה באמת צריך להיות מוגרן

בהתחלה מבצעים מיפוי מלא, מעבר ל“כמה טבלאות“ בלבד. בפרויקטי Paradox/BDE נפוץ שמסד הנתונים הוא רק חלק מהאמת. נקודות חשובות:

1) טבלאות, אינדקסים, „מפתחות פסאודו“

לעתים קרובות חסרים מפתחות ראשיים אמיתיים. במקום זאת קיימות קומבינציות של שדות, מספרי רץ ללא Constraint ברור או שדות „Key“ שמנוהלים ביישום. ב-MariaDB יש להפוך אותם למפתחות ייחודיים ואמינים — אחרת טרנזקציות ושלמות רפרנציאלית יהיו מוגבלות באפקטיביות.

2) שאילתות, בלוקי SQL דינמיים, דוחות

BDE משתמש בדיאלקטים שונים של SQL לפי רכיב ומאפשר ביטויים „יצירתיים“. רכיבי דיווח (גם ישנים) מכילים לעתים הגדרות SQL משלהם. הגירה חייבת למצוא ולסווג מקורות אלה: שאילתות ליבה קריטיות, ניתוחים שנדירים בשימוש, ייבואים מיוחדים.

3) מערך תווים ותווים מיוחדים (Umlaute, ISO/ANSI, Unicode)

רבים מיישומי Paradox היסטורית מבוססים על ANSI. אם יישום Delphi הועבר בעבר ל-Unicode מתרחשות מערכות מעורבות: נתונים באנקודינג ישן, ממשק משתמש ב-Unicode, ייצוא שמצפה ל-Windows-1252. ל-MariaDB צריך להיות קונספט ברור (בדרך כלל utf8mb4), כולל המרה נקייה ובדיקות לטעויות „בלתי נראות“ (השוואות, מיון, Trim/Pad, תווים מיוחדים).

4) ערכים „ריקים“, לוגיקת NULL ושדות תאריך

Paradox/BDE מכירים מצבים מיוחדים: מחרוזות ריקות במקום NULL, תאריכים עם ערך 0, טיימסטאפים „ריקים“, ערכי ברירת מחדל שנוצרים בממשק. ב-MariaDB קיימת הבחנה נוקשה בין NULL לריק. זה משפיע על WHERE, אגראגציות וחישובים. יש להעריך הבדלים אלה לכל טבלה/שדה.

5) ארטיפקטים נלווים: טבלאות סשן, קונפיג מקומי, cache

לעתים במבנה Paradox קיימות טבלאות מקומיות לתוצאות ביניים, buffers לייצוא, פריסות משתמש או פרמטרים. חלקן שייכות להישאר מקומיות (למשל פריסות UI), אחרות צריכות להיות מרכזיות (למשל תהליכי עבודה, סטטוסים, לוגים). הגירה היא הזדמנות להפרדה ברורה של קטגוריות אלו.

מכשולים ב-Paradox/BDE: הבדלים טכניים טיפוסיים

כדי להפוך את ההגירה לתכנון ישיר, כדאי לטפל במפורש בהבדלים החוזרים.

דיאלקט SQL ואופרטורים

BDE/Paradox-SQL אינם זהים ל-MySQL/MariaDB-SQL. הבדלים מופיעים בפונקציות תאריכים, פונקציות מחרוזת, Outer Joins היסטוריים, לוגיקת Like/מסכות ובהמרות טיפוס סמיות. גישה מבוקרת מחליפה „פועל בסדר“ בחוקים ברורים: אילו ביטויים מועברים, אילו נכתבים מחדש במכוון, ואילו נארזים ב-Views/Stored Procedures (כאשר יש הגיון לכך).

מיון ו-Collation

ב-Paradox סדרי המיון והרגישות לאותיות גדולות/קטנות לעתים שונים מ-MariaDB, במיוחד בנוגע לאומלאוטים. ב-MariaDB ה-Collation (למשל utf8mb4_german2_ci לעומת utf8mb4_unicode_ci) קובע השוואה ומיון. זה לא שאלה תאורטית: זה משפיע על דדופליקציה, פונקציות חיפוש והתנהגות של Unique-Constraints.

Autoincrement ומעגלי מספרים

ל-Paradox יש שדות Autoincrement, אבל יישומים משתמשים לעתים קרובות במעגלי מספרים עסקיים (מספרי מסמכים, מספרי הזמנה) עם לוגיקה ייחודית. ב-MariaDB יש להפריד בבירור:

• מפתח ראשי טכני: AUTO_INCREMENT (או UUID, בהתאם לארכיטקטורה) לקשרים.
• מספר מקצועי: מעגל מספרים נפרד עם הגנה טרנזקציונית, אפשרי לפי לקוח/תקופה.

מי שמנצל מספר מקצועי כמפתח טכני ייאלץ לשנות מבנים יקרים בעתיד.

נעילות וטרנזקציות

המעבר מגישה מבוססת קבצים לשרת אמיתי הוא יתרון, אך משנה את ההתנהגות. ב-MariaDB טרנזקציות (InnoDB) מרכזיות. צריך להחליט היכן עובר גבול הטרנזקציה: לשיחה, לפעולת שמירה או לאצווה. חשוב במיוחד: טרנזקציות ארוכות ומצב עריכה שנמשך דקות נפוצים ביישומי Paradox, אך בצד השרת מגבירים סיכוני נעילות, deadlocks ועיכוב שכפול. התאמת שיטות עבודה או הממשק היא פעמים רבות חלק מההגירה.

מודל פעולה: הגירה מבוקרת בשלבים במקום Big Bang

בסביבות B2B יציבות תפעולית חשובה יותר מחיתוך מהיר. מסלול הגירה בשלבים מוריד סיכונים כי היחידות העסקיות וה-IT יכולות לאמת באופן איטרטיבי.

שלב 1: העתקת מודל נתונים עם מיפוי, ללא שינויים בקוד

בשלב הראשון בונים סקימה ב-MariaDB שמדמה את מבנה Paradox — אך כבר לפי עקרונות היעד: Primary Keys, אינדקסים, טיפוסי נתונים סבירים, utf8mb4, InnoDB. במקביל מפתחים תהליך ייבוא רב-שימושי (סקריפטים/כלים) שניתן להריץ שוב ושוב. חשובה היכולת לשחזור, כיוון שהגירה לעולם אינה „גמורה“ בריצה הראשונה.

Deliverables טיפוסיים בשלב זה הם:

• הגדרת Schema (DDL) בגרסאות (למשל ב-Git)
• רשימת מיפוי שדות (Paradox → MariaDB) כולל כללי המרה
• פרוצדורת ייבוא עם רישום לוגים (מספר רשומות, שגיאות, ערכים חריגים)
• דוחות אימות ראשוניים (Counts, סיכומים, Checksums)

שלב 2: החלפת BDE בגישה הנתונים (לדוגמה עם FireDAC)

שלב המודרניזציה העיקרי הוא ניתוק מ-BDE. בפרויקטים של Delphi BDE-Ablosung mit nativer Anbindung הוא דרך מבוססת כיוון שהוא מספק דרייברים מודרניים, טרנזקציות, קשירת פרמטרים ורכיבים אחידים למסדי SQL שונים. ההכרעה אינה רק „להוציא את BDE“, אלא כיצד הקוד ייראה אחר כך: גישת גישה מרכזית לנתונים, טיפול שגיאות ברור, פרמטרים נקיים במקום שרשור מחרוזות.

משימות טיפוסיות בשלב זה:

• החלפת TTable/TQuery ב-FireDAC-Queries ו-DataSets
• הכנסת שכבת Data-Access (DAL) כבסיס לארכיטקטורת Layer-3 בהמשך
• סטנדרטיזציה של שולחי טרנזקציה (Commit/Rollback)
• סקירת SQL: התאמת דיאלקט, פרמטרים, Paging, Joins

אם היישום שלכם מיועד למודרניזציה ארוכת טווח, שלב זה לעתים קריטי יותר מההגירה הנתונים בלבד. הוא יוצר חופש טכני עבור 64‑Bit, גרסאות מודרניות של Windows וצינורות פריסה נקיים.

שלב 3: ריצה מקבילה ואישורים מקצועיים ללא שבירת תפעול

למערכות קריטיות ריצה מקבילה היא פתרון נכון: MariaDB נבנית וממולאת באופן מחזורי (או אינקרמנטלי) בזמן שהמערכת הישנה ממשיכה לפעול. כך המחלקה המקצועית יכולה להשוות דוחות, לזהות מקרי קצה ולבחון את הפלטפורמה החדשה בעומס. אפשר לממש ריצה מקבילה בכמה אופנים:

• שכפול לקריאה בלבד לצורך דיווח/הכנה ל-BI
• „Dual Write“ באזורים מוגדרים בלבד (רק אם נשלט היטב)
• הגירה לפי מועד עם מספר Dry Runs ורשימת בדיקות Cutover ברורה

חשוב לא להיעזר ביותר מדי מורכבות: Dual-Write נשמע מפתה אך טעון שגיאות כאשר הלוגיקה העסקית אינה מרוכזת. לעתים ריצה חוזרת של Cutover עם אימות טוב נבונה יותר כלכלית.

שלב 4: אופטימיזציה, שלמות, ביצועים ותהליכי תפעול

אחרי ה-Cutover מתחילה ההזדמנות שמMariaDB תציג את יתרונותיה: שלמות רפרנציאלית, אינדקסים מהירים, הרשאות נקיות, ניטור, מבחני גיבוי/שחזור. כאן נחשפים לעתים העומסים האמיתיים: דוחות ארוכים, מסכים שמחפשים ללא אינדקסים מתאימים, עדכוני אצווה כבדים. הגירה מבוקרת כוללת שלב זה במפורש במקום להותירו כעבודה לא מתוכננת.

סוגי נתונים ומיפוי: מ-Paradox ל-MariaDB בלי אובדן מידע

מיפוי השדות הוא ליבת ההגירה. התאמות טיפוס טיפוסיות (מפושטות) הן:

• Alpha / Memo: VARCHAR/TEXT (עם utf8mb4), בדיקות אורך וכללי Trim
• Number: INT/BIGINT/DECIMAL לפי טווח הערכים; זהירות בעשרוניות סמיות
• Date/Time: DATE/DATETIME/TIMESTAMP; כללים ברורים עבור „תאריך 0“ או NULL
• Logical: BOOLEAN או TINYINT(1) עם סמנטיקה ברורה
• Currency: DECIMAL(…,2/4) במקום Float כדי למנוע שגיאות עיגול

חשוב לא רק לתרגם טיפוסי נתונים, אלא גם לתעד כללי מקצוע: האם שדה יכול להיות NULL? איזה ערכי ברירת מחדל נכונים מבחינה מקצועית? אילו קומבינציות חייבות להיות ייחודיות? מכאן נוצרים Constraints ואינדקסים. כללים אלה היו במערכות Paradox/BDE פעמים רבות מרומזים בממשק או בקוד — ב-MariaDB יש להפוך אותם מפורשים כאשר זה רלוונטי.

שלמות: מפתחות ראשיים, מפתחות זרים ואינדקסים ייחודיים

רבות מהמסדי נתונים הישנים פעלו שנים ללא שלמות רפרנציאלית — עד שחיבורים, פורטלים או תהליכים מקבילים נכנסו למשחק. אז איכות הנתונים הופכת למגבלה. ב-MariaDB ניתן להפעיל Foreign Keys, Unique Constraints ו-Checks (בהתאם לגרסה/מנוע) כדי למנוע שגיאות נתונים מוקדם.

דרך מעשית היא להכניס שלמות בשלבים:

• ראשית Primary Keys ואינדקסים ייחודיים על אובייקטים מרכזיים (לקוחות, פריטים, מסמכים)
• לאחר מכן Foreign Keys באזורים יציבים
• לטבלאות „היסטוריות“ עם נתוני לכלוך: תחילה ניקוי, אחר כך Constraints

זה מוריד סיכון שה-Cutover ייכשל בגלל חוב ישן ומשפר משמעותית את המצב הכללי.

ביצועים במציאות: מה משתנה עם MariaDB

מערכות Paradox/BDE פעמים רבות מותאמות למהירות קבצים מקומית: אינדקסים מקומיים, גישה מהירה לטבלאות וסינון בצד הלקוח. ב-MariaDB משימות רבות עוברות לשרת. זה טוב, אך דורש אסטרטגיות SQL ואינדקסים נקיים.

מלכודות ביצועים טיפוסיות

• SELECT * מטבלאות גדולות, כי קודם זה היה „מהיר“ מקומית
• סינון בצד הלקוח במקום WHERE בצד השרת
• חוסר אינדקסים מרוכבים לשדות חיפוש משולבים (למשל Mandant + Status + Datum)
• LIKE ‚%text%‘ ללא אסטרטגיית חיפוש מתאים (Fulltext וכו‘)

שיפור מדיד במקום „על הרגש“

הגירה מבוקרת מגדירה מוקדם נקודות מדידה: Slow Query Log, Explain-ניתוחים, מבחני עומס ששחזרו תרחישים. זה קריטי כשלאחר ההגירה מתוכננות רכיבים נוספים, למשל REST-Server או Kundenportal, שיוצרים דפוסי גישה חדשים (הרבה בקשות קטנות, Paging, נקודות חיפוש).

ספציפי ל-Delphi: החלפת BDE, FireDAC ושכבות גישה נקיות

בפרויקטים של Delphi המודרניזציה הטכנית קשורה בקשר הדוק לגישת הנתונים. BDE אינה רק „דרייבר“, אלא סגנון גישה שלם (TTable, גישת רשומות, ניווט, מסננים מקומיים). ההגירה ל-MariaDB היא הרגע המתאים לזהות ולרכז את גישת הגישה.

מ-„DataSets בכל מקום“ לגישה מבוקרת לנתונים

יישומים רבים מחזיקים שאילתות בכל טופס בנפרד. זה לא קנה מידה מבחינה מקצועית ובטיחותית. השינוי המוצלח הולך לכיוון:

• מחלקות Repository/Service מרכזיות לאובייקטים ליבתיים
• טיפול שגיאות וטרנזקציות אחיד
• שאילתות פרמטריות (מניעת SQL Injection, שימוש ב-Plan-Caching)
• ניהול Connection-Pools או Connection-Management ניתן לתצורה לשירותים

כך נוצרת תשתית לארכיטקטורת Layer-3 שבה UI, לוגיקה מקצועית ו-Persistence מופרדים נקי. זה לא עוזר רק במעבר מסד נתונים, אלא גם בפיתוח בהמשך של REST-Server או שירותי רקע.

חיבור MariaDB עם FireDAC: מה בדרך כלל צריך להבהיר

בפרויקטים עולות תמיד אותן שאלות: איזו גרסת דרייבר (MySQL/MariaDB), אילו אופציות SSL, איזה הגדרות אזור זמן ותאריכים, אילו הגדרות Unicode? אלה אינם פרטים כי הם משפיעים ישירות על עקביות נתונים (תאריך/שעה), מיון ובטיחות תפעולית (TLS). הגירה מבוקרת מגדירה פרמטרים אלה, מתעדת אותם ובודקת על דטה ריאליסטי.

תוכנית Cutover: יום מעבר, הקפאת נתונים, Rollback — ללא הפתעות

ה-Cutover הוא פרויקט בפני עצמו. תוכנית Cutover טובה אינה רק „מתי מעבירים“, אלא גם צעדי הגנה:

• הקפאת נתונים: מאיזה רגע לא נרשמים עוד נתונים במערכת הישנה? האם קיימים תהליכי חירום?
• ייבוא סופי: כמה זמן ייקח באופן ריאלי? (Dry Runs נותנים נתונים.)
• אימות: אילו בדיקות חייבות לעבור לפני אישור הפתיחה (Counts, סיכומים, דגימות, דוחות מקצועיים)?
• Rollback: מתי מפסיקים וכיצד ממשיכים במקרה של כישלון?
• תקשורת: מי נותן אישור? מי זמין ב-War Room?

בעסקים בינוניים Rollback לעתים קרובות אינו בעיה טכנית אלא ארגונית. לכן יש להכין את ההגירה כך שה-Cutover לא יהיה ניסוי אלא תהליך מאומן.

לאחר ההגירה: בסיס ל-REST, שירותים ומולטיפלטפורם

כאשר MariaDB יציבה והחלפת BDE בוצעה כהלכה, נפתחות אפשרויות חדשות: REST-APIs למערכות חיצוניות, עיבוד רקע כ-Windows- או Linux-Services, פירוק UI והלוגיקה המקצועית והרחבה עתידית ללקוחות רב-פלטפורמיים. הצעד הבא הנפוץ הוא לחלץ לוגיקה מקצועית מהדסקטופ כדי לשרת בצורה מבוקרת אינטגרציות (ERP/DMS/CRM) ופורטלים.

חשוב לזכור: REST-Server אינו „שכבה נוספת“ בלבד אלא החלטת ארכיטקטורה. מי שכבר ריכז גישת נתונים, ולידציות והרשאות בשירותים/Repositories יכול לפתח API חזק הרבה יותר בקלות.

מבחן מעשי: מה כדאי להבהיר לפני תחילת הפרויקט

• אילו מודולים הם קריטיים לעסק וחייבים לפעול ביום ה-Cutover?
• כיצד נראים נפחי הנתונים האמיתיים (גודל טבלאות, קצב גדילה, מדיניות ארכוב)?
• אילו דוחות חייבים להיות זהים 1:1 ואילו יכולים להשתפר?
• אילו אינטגרציות תלויות במערכת (ייצוא קבצים, ODBC, Office, מסלולי הדפסה)?
• האם קיימת יכולת מולטי-טננט, ואם כן — כיצד היא מיוצגת היום?
• אילו דרישות תפעוליות חלות (חלון גיבוי, זמן שחזור, הרשאות, Audit)?

בהירות בנושא אלה אינה בירוקרטיה אלא מונעת מצב שבו הגירה „טכנית“ מושלמת אך אינה מקובלת מקצועית.

סיכום: הגירה מבוקרת פירושה הפיכת סיכונים לניתנים לתכנון

הגירה מבוקרת של Paradox ו-BDE ל-MariaDB פירושה מודרניזציה של היישום כמערכת כוללת: מודל נתונים, SQL, טרנזקציות, מערכות תווים, שכבת גישה ותהליכי תפעול. מי שרואה את המעבר כייצוא בלבד בדרך כלל מקבל בדיוק את הבעיות שרצה להיפטר מהן — רק על שרת חדש.

גישה בשלבים עם ייבוא שניתן לשחזור, מיפוי שדות נקי, אימות מוקדם והחלפת BDE ברורה (למשל באמצעות FireDAC) יוצרת לעומת זאת בסיס יציב: לפעולה מרובת משתמשים, לאינטגרציות, לשירותים ולשלבים הבאים של Delphi Modernisierung.

אם אתם רוצים לתכנן את ההגירה באופן מקצועי ולבצע אותה ללא שבירת תפעול, נשמח לדון במצב ההתחלתי, בסיכונים ובתוכנית שלבים ריאליסטית: https://net-base-software-gmbh.de/kontakt/