דריסה שקטה קורית כששני אנשים שומרים את אותה שורה. מה קורה ב-Google Sheets, באקסל על שיתוף רשת ובתיבת Write Conflict של Access, ואיזו בקרה עוצרת את זה.
עיקרי הדברים
- הבעיה אינה "שני אנשים בקובץ" אלא "שני אנשים ששמרו את אותה שורה", ובין שתי הנקודות האלה עוברות לרוב כמה דקות.
- שיתוף פעולה בו-זמני באקסל עובד רק ב-OneDrive או ב-SharePoint. נתיבים כמו \\\\server\\folder אינם תומכים בו.
- מספיק שמשתמש אחד פותח את הקובץ בגרסה שאינה תומכת בעריכה משותפת - וכל השאר יקבלו הודעת נעילה.
- Access מציג תיבת Write Conflict עם שלוש אפשרויות, ואחת מהן דורסת בשקט את עבודת האחר.
- הפתרון היציב הוא שדה גרסה לכל שורה, כך שהשמירה השנייה נדחית במקום להצליח בשקט.
דריסה שקטה מתרחשת כששני אנשים טוענים את אותה שורה, שניהם עורכים אותה, והשמירה השנייה מחליפה את הראשונה בלי שאיש יקבל התראה. Google Sheets ממזג עריכות ברמת התא. קובץ אקסל על שיתוף רשת לא ממזג כלל. הבקרה הנדרשת נגזרת מהמקום שבו הקובץ יושב.
דריסה שקטה, דקה אחר דקה
דנה מטפלת בהזמנות, עמיר מטפל במלאי. שניהם עובדים באותו גיליון הזמנות. אף אחד מהם לא עשה שום דבר שגוי.
| שעה | דנה | עמיר | מה יש בשורה 412 |
|---|---|---|---|
| 09:14 | פותחת את הקובץ, רואה שורה 412 | - | כמות 12, סטטוס "ממתין" |
| 09:16 | - | פותח את הקובץ, רואה אותה שורה | כמות 12, סטטוס "ממתין" |
| 09:19 | מעדכנת כמות ל-9 אחרי שיחה עם הלקוח | - | כמות 9 |
| 09:23 | - | משנה סטטוס ל"נשלח" ושומר מהעותק שלו | כמות 12, סטטוס "נשלח" |
| 09:40 | מדפיסה תעודת משלוח | - | 12 יחידות במקום 9 |
השינוי של דנה נעלם ב-09:23. לא הופיעה שגיאה, אף אחד לא נשאל דבר, והתגלית מגיעה בהחזרה מהלקוח. זו דריסה שקטה: לא באג ולא רשלנות, אלא התנהגות ברירת המחדל של כלי שאין בו בקרת עדכון.
למה Google Sheets שורד את זה וקובץ אקסל על שיתוף רשת לא?
כי הם פועלים על יחידה אחרת. Google Sheets משדר כל עריכה בנפרד וממזג אותה ברמת התא, ולכן שני אנשים שעורכים תאים שונים באותה שורה לא דורסים זה את זה. אקסל על שיתוף רשת מסורתי עובד ברמת הקובץ: מי שפתח ראשון מחזיק את הנעילה, והשני מקבל את הקובץ לקריאה בלבד או שומר עותק.
מיקרוסופט מתעדת את התנאים במפורש. עריכה משותפת דורשת שהקובץ יישמר ב-OneDrive, ב-OneDrive for Business או ב-SharePoint, ואינה נתמכת בנתיבי שרת מסוג \\server\folder ובענני צד שלישי. שתי מלכודות נוספות מפילות אותה גם כשהקובץ במקום הנכון:
- משתמש אחד פותח בגרסת Office שאינה תומכת בעריכה משותפת, וכל השאר מקבלים את הודעת הנעילה.
- לקובץ יש טבלת ציר או חיבור נתונים עם האפשרות "רענן נתונים בעת פתיחת הקובץ" מסומנת. האפשרות הזו מבטלת עריכה משותפת.
איפה שמור הקובץ קובע איזו תקלה תקבלו
| המיקום | מנגנון הבקרה | מה קורה בהתנגשות | מה מאבדים |
|---|---|---|---|
| Google Sheets | מיזוג ברמת התא | שתי העריכות נשמרות | ערך אחד בתא בודד, אם שניהם הקלידו באותו תא |
| Excel ב-OneDrive או SharePoint | עריכה משותפת עם שמירה אוטומטית | שינויים מוצגים תוך שניות | לרוב כלום, כל עוד כולם בגרסה תומכת |
Excel על \\server\folder | נעילה ברמת קובץ | השני מקבל קריאה בלבד או עותק | קובץ שלם, אם נשמר עותק ומישהו ממשיך בו |
| Access עם קובץ מפוצל | נעילה ברמת רשומה | תיבת Write Conflict | רשומה, לפי הכפתור שנלחץ |
| בסיס נתונים עם שדה גרסה | בקרה אופטימית | השמירה השנייה נדחית עם הודעה | כלום - המשתמש מתבקש לטעון מחדש |
השורה האחרונה היא היחידה שבה ההתנגשות הופכת לאירוע גלוי. בכל השאר היא נפתרת ברקע, ולעיתים לרעת מישהו.
התשובה של Access: תיבת Write Conflict
כשמערכת Access מפוצלת לחזית ולעורף, הנעילה היא ברמת הרשומה, ומשתמש שמנסה לשמור רשומה שהשתנתה בינתיים מקבל תיבת Write Conflict עם שלוש אפשרויות:
- Save Record - דורס את השינוי של האחר. מי שהחזיק בנעילה מנצח, והאחר מאבד את עבודתו.
- Copy to Clipboard - מעתיק את הרשומה עם השינויים שלכם ללוח, ומציג את השינויים של האחר. אפשר להשוות ולהחליט.
- Drop Changes - מוותרים על השינוי שלכם ומשאירים את של האחר.
הכפתור האמצעי הוא היחיד שמשמר את שתי הגרסאות, והוא גם זה שכמעט אף אחד לא לוחץ עליו. שווה להזכיר גם מקרה מבלבל שמיקרוסופט מתעדת: התיבה מופיעה גם כשמשתמש אחד פתח את אותה רשומה בטופס ובטבלה במקביל. "המשתמש האחר" הוא אז אתם.
מה עולה "השמירה האחרונה מנצחת", ואיך עוצרים אותה
שתי גישות עובדות, והן לא מוציאות זו את זו:
- בקרה אופטימית לפי גרסה. לכל שורה יש שדה שמשתנה בכל עדכון. הלקוח שולח את הערך שהוא קרא; אם הוא כבר לא זהה, השמירה נדחית. ב-SQL Server זהו טיפוס
rowversion, ו-Access משתמש בו בטבלה מקושרת כדי לזהות מתי הרשומה עודכנה לאחרונה. - בעלות על שדה, לא על שורה. דנה אחראית לכמות, עמיר לסטטוס. אם כל אחד כותב לשדות שלו בלבד, ההתנגשות פשוט לא קיימת. זו הגישה הזולה ביותר וכמעט תמיד המתאימה ביותר בגיליון תפעולי.
הגישה השלישית, נעילה פסימית - לנעול את השורה לעריכה בלעדית - נכונה בעסקאות קצרות ומזיקה כשמישהו יוצא לפגישה עם השורה נעולה.
אילו שאלות עונים לפני שבוחרים מנגנון?
- כמה זמן חולף בין הרגע שבו נטענת שורה לרגע שבו היא נשמרת? חמש שניות ושתי דקות הן בעיות שונות.
- האם שני האנשים נוגעים באותו שדה, או רק באותה שורה?
- כמה עולה השחזור של דריסה שהתגלתה יומיים אחרי? זה קובע כמה בקרה מוצדקת.
- האם דרוש תיעוד מי שינה מה? ב-Google Sheets יש לחיצה ימנית על תא > הצגת היסטוריית עריכה, וכן היסטוריית גרסאות לקובץ.
- מי מוסמך להכריע כששתי הגרסאות תקפות?
בקרות שאפשר להוסיף לגיליון כבר השבוע
- העברת הקובץ ל-OneDrive או ל-SharePoint אם הוא יושב על שיתוף רשת, כדי לקבל עריכה משותפת אמיתית.
- הגדרת טווחים מוגנים כך שכל תפקיד כותב רק לעמודות שלו.
- הוספת עמודות "עודכן על ידי" ו"עודכן בתאריך" שנכתבות אוטומטית.
- ביטול הסימון של "רענן נתונים בעת פתיחת הקובץ" בכל טבלת ציר וחיבור נתונים בקובץ.
- הפרדה בין קלט לדוחות, כך ששני אנשים לא כותבים לאותה לשונית מלכתחילה.
- קביעת כלל אחד ברור מי מעדכן איזה שדה - ורישומו בגיליון עצמו, לא בזיכרון של מישהו.
כשההתנגשויות מגיעות מבסיס הנתונים ולא מהגיליון, התסמינים אחרים - ראו אבחון נעילות והשהיות ב-SQL. ואם הגיליון עצמו הפך לתשתית, שווה לקרוא מתי גיליון גדל מעבר לגודלו והעברת ידע מגיליון של אדם אחד.
מקורות
שאלות נפוצות
איך מזהים בדיעבד שנתון נדרס?
ב-Google Sheets: לחיצה ימנית על התא ובחירת הצגת היסטוריית עריכה מציגה מי שינה את הערך ומתי, ולצידה היסטוריית הגרסאות של הקובץ כולו. Google מציינת שחלק מהשינויים אינם מופיעים בהיסטוריה, ולכן זה כלי חקירה - לא ראיה מלאה.
האם נעילת הקובץ פותרת את הבעיה?
היא מונעת דריסה ויוצרת תור. משתמש אחד עובד, כל השאר ממתינים, ומי שיצא לארוחת צהריים עם הקובץ פתוח עוצר את המחלקה. בתהליך שבו שני אנשים נוגעים בשדות שונים באותה שורה, חלוקת בעלות על שדות עדיפה על נעילה כמעט תמיד.
למה קיבלנו הודעת נעילה למרות שהקובץ ב-SharePoint?
הגורם השכיח הוא משתמש אחד שפתח בגרסת Office שאינה תומכת בעריכה משותפת - די באחד כדי לחסום את כולם. גורם שני הוא טבלת ציר או חיבור נתונים בקובץ שבו מסומן "רענן נתונים בעת פתיחת הקובץ", אפשרות שמבטלת עריכה משותפת.
מה זה rowversion ולמה זה עוזר?
`rowversion` הוא טיפוס ב-SQL Server שערכו משתנה אוטומטית בכל עדכון של השורה. אפליקציה ששולחת את הערך שקראה מקבלת דחייה אם הוא כבר אינו זהה, כלומר מישהו הקדים אותה. Access משתמש בשדה הזה בטבלה מקושרת כדי לזהות שהרשומה עודכנה.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.