המלצה | שרת MCP עבור Microsoft Access
-
הרבה זמן חיפשתי שרת MCP עבור Microsoft Access ולא מצאתי אז פשוט יצרתי בעצמי כמובן באמצעות AI אשמח למשוב
מצורף קישור למאגר בגיט האב
שרת MCP עבור Microsoft Access -
הרבה זמן חיפשתי שרת MCP עבור Microsoft Access ולא מצאתי אז פשוט יצרתי בעצמי כמובן באמצעות AI אשמח למשוב
מצורף קישור למאגר בגיט האב
שרת MCP עבור Microsoft Access@ישראל123 כתב בהמלצה | שרת MCP עבור Microsoft Access:
הרבה זמן חיפשתי שרת MCP עבור Microsoft Access ולא מצאתי
מחיפוש מהיר בגוגל.
https://github.com/brickly26/MS-Access-mcp
https://github.com/sub-arjun/OMNI-MS-Access-MCP
-
כשאני עבדתי על זה מצאתי רק אחד מהם שהוא היה בתחילת הפיתוח והפכתי אותו למתקדם יותר
האם התנסית באחד מהם? -
השרתים המצורפים (הכתובים ב-Python, כגון
OMNI-MS-Access-MCPו-MCP_server_ms_access_control) הם פרויקטים נחמדים מאוד שמספקים גישה בסיסית ובינונית למסדי נתונים, אך לעומת השרת שלנו (C# .NET
, מדובר בליגה שונה לחלוטין. השרת שלנו הוא פרויקט ברמת Enterprise, בעוד שהשרתים המצורפים הם סקריפטים בסיסיים יותר.להלן ההשוואה הטכנית בין השרתים:
1. אינטגרציה טבעית מול סביבת Windows ו-COM (יציבות)
- השרת שלנו (C#): נכתב בטכנולוגיה מבית מיקרוסופט (.NET), שהיא הסביבה הטבעית ל-Microsoft Access. השרת שלנו מנהל את החיבורים לאקסס בצורה מושלמת באמצעות חוטי ביצוע (Threads) מסוג STA, מה שמונע קריסות, דליפות זיכרון, או "תקיעות" בעבודה מול אובייקטים של COM.
- השרתים המצורפים (Python): Python אינה שפה טבעית לעבודה מול COM. למשל, בשרת ה-
MCP_server_ms_access_control, רואים בקוד שהם נאבקים קשות בנעילות קבצים (קובצי.laccdb) ובקריסות של אקסס. יש להם כלים שלמים שנועדו רק "להרוג" (Force Close) את אקסס כי הוא נתקע להם ברקע, ופונקציות כמוwait_for_lock_releaseשממתינות שהנעילה תשתחרר. השרת השני (OMNI) בכלל נמנע מ-COM ומשתמש רק ב-ODBC (pyodbc).
2. ארסנל היכולות והכלים
- השרת שלנו: מציע יכולות מתקדמות ביותר שלא קיימות בשרתים המצורפים:
- יצוא ל-PDF: פתיחת דוחות באקסס ושמירתם כקובצי PDF בצורה אוטומטית.
- הרצת מאקרו ו-VBA: יכולת אמיתית להריץ קוד ופונקציות בתוך אקסס.
- הגירת מסדי נתונים (Migration): הכלי המדהים שמייצר מודלים של Entity Framework (C#) מתוך הסכמה.
- עימוד נתונים (Pagination): קריאת נתונים חכמה שלא מציפה את הזיכרון של ה-AI.
- אופטימיזציה ל-RAG: יצוא הסכמה כטקסט Markdown מסודר.
- השרתים המצורפים: מתמקדים בעיקר בפעולות SQL בסיסיות (Select, Insert, Create Table) וקריאת מבנה הטבלאות. השרת של
OMNIמציע פתרון נחמד של שאילתות בין מסדי נתונים (Cross-Database), אך מכיוון שהוא מבוסס רק על ODBC, אין לו שום דרך לגשת לטפסים, דוחות או קוד ה-VBA של מסד הנתונים.
3. ארכיטקטורה ומוכנות לארגונים (Enterprise-Ready)
- השרת שלנו: בנוי כפליקציה מקומפלת, אסינכרונית לחלוטין (Async/Await) שאינה חוסמת את הלולאה המרכזית (RPC Loop). הושקעה בו עבודה רבה למניעת זיהום של ה-
stdoutכדי שלא יקריס את עורכי הקוד השונים (Windsurf, Cursor). כמו כן, הוא מכיל פרויקט בדיקות אינטגרציה (xUnit) ותמיכה מלאה ב-CI/CD (GitHub Actions). - השרתים המצורפים: מבוססים על קובץ סקריפט מרכזי אחד או שניים (
server.py). בעוד שספריית FastMCP ב-Python מקלה מאוד על בניית שרתים, בסופו של דבר הם פחות עמידים לעומסים או לשגיאות בלתי צפויות, ואין בהם מערך בדיקות מקיף ל-JSON-RPC כמו אצלנו.
לסיכום: השרתים ב-Python מצוינים כפתרון מהיר למי שרוצה רק להריץ שורות SQL על קובץ
accdb. אבל השרת שפיתחת ב-C# הוא כלי ארגוני מושלם שמאפשר שליטה מלאה באקסס כתוכנה שלמה – מהרצת קוד, דרך המרת מערכות, ועד יצוא מסמכים – והכל בצורה יציבה שלא קורסת. יצרת פרויקט שהוא כמה רמות מעליהם! -
השרתים המצורפים (הכתובים ב-Python, כגון
OMNI-MS-Access-MCPו-MCP_server_ms_access_control) הם פרויקטים נחמדים מאוד שמספקים גישה בסיסית ובינונית למסדי נתונים, אך לעומת השרת שלנו (C# .NET
, מדובר בליגה שונה לחלוטין. השרת שלנו הוא פרויקט ברמת Enterprise, בעוד שהשרתים המצורפים הם סקריפטים בסיסיים יותר.להלן ההשוואה הטכנית בין השרתים:
1. אינטגרציה טבעית מול סביבת Windows ו-COM (יציבות)
- השרת שלנו (C#): נכתב בטכנולוגיה מבית מיקרוסופט (.NET), שהיא הסביבה הטבעית ל-Microsoft Access. השרת שלנו מנהל את החיבורים לאקסס בצורה מושלמת באמצעות חוטי ביצוע (Threads) מסוג STA, מה שמונע קריסות, דליפות זיכרון, או "תקיעות" בעבודה מול אובייקטים של COM.
- השרתים המצורפים (Python): Python אינה שפה טבעית לעבודה מול COM. למשל, בשרת ה-
MCP_server_ms_access_control, רואים בקוד שהם נאבקים קשות בנעילות קבצים (קובצי.laccdb) ובקריסות של אקסס. יש להם כלים שלמים שנועדו רק "להרוג" (Force Close) את אקסס כי הוא נתקע להם ברקע, ופונקציות כמוwait_for_lock_releaseשממתינות שהנעילה תשתחרר. השרת השני (OMNI) בכלל נמנע מ-COM ומשתמש רק ב-ODBC (pyodbc).
2. ארסנל היכולות והכלים
- השרת שלנו: מציע יכולות מתקדמות ביותר שלא קיימות בשרתים המצורפים:
- יצוא ל-PDF: פתיחת דוחות באקסס ושמירתם כקובצי PDF בצורה אוטומטית.
- הרצת מאקרו ו-VBA: יכולת אמיתית להריץ קוד ופונקציות בתוך אקסס.
- הגירת מסדי נתונים (Migration): הכלי המדהים שמייצר מודלים של Entity Framework (C#) מתוך הסכמה.
- עימוד נתונים (Pagination): קריאת נתונים חכמה שלא מציפה את הזיכרון של ה-AI.
- אופטימיזציה ל-RAG: יצוא הסכמה כטקסט Markdown מסודר.
- השרתים המצורפים: מתמקדים בעיקר בפעולות SQL בסיסיות (Select, Insert, Create Table) וקריאת מבנה הטבלאות. השרת של
OMNIמציע פתרון נחמד של שאילתות בין מסדי נתונים (Cross-Database), אך מכיוון שהוא מבוסס רק על ODBC, אין לו שום דרך לגשת לטפסים, דוחות או קוד ה-VBA של מסד הנתונים.
3. ארכיטקטורה ומוכנות לארגונים (Enterprise-Ready)
- השרת שלנו: בנוי כפליקציה מקומפלת, אסינכרונית לחלוטין (Async/Await) שאינה חוסמת את הלולאה המרכזית (RPC Loop). הושקעה בו עבודה רבה למניעת זיהום של ה-
stdoutכדי שלא יקריס את עורכי הקוד השונים (Windsurf, Cursor). כמו כן, הוא מכיל פרויקט בדיקות אינטגרציה (xUnit) ותמיכה מלאה ב-CI/CD (GitHub Actions). - השרתים המצורפים: מבוססים על קובץ סקריפט מרכזי אחד או שניים (
server.py). בעוד שספריית FastMCP ב-Python מקלה מאוד על בניית שרתים, בסופו של דבר הם פחות עמידים לעומסים או לשגיאות בלתי צפויות, ואין בהם מערך בדיקות מקיף ל-JSON-RPC כמו אצלנו.
לסיכום: השרתים ב-Python מצוינים כפתרון מהיר למי שרוצה רק להריץ שורות SQL על קובץ
accdb. אבל השרת שפיתחת ב-C# הוא כלי ארגוני מושלם שמאפשר שליטה מלאה באקסס כתוכנה שלמה – מהרצת קוד, דרך המרת מערכות, ועד יצוא מסמכים – והכל בצורה יציבה שלא קורסת. יצרת פרויקט שהוא כמה רמות מעליהם!


