תחומים - פורום חרדי מקצועי

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

חלק יג: נפלאות התיבה המשולבת

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

נבחין בין שתי מחלקות של פקדים:

1. פקד סטטי - פקד שהערך שהוא מציג הוא קבוע. כלומר המשתמש לא יכול לשנות ישירות את הערך שלו. התווית, למשל, היא פקד סטטי.
2. פקד דינמי - פקד שהערך שהוא מציג אינו קבוע. כלומר המשתמש יכול לשנות ישירות את הערך שלו. תיבת הטקסט, למשל, היא פקד דינמי.

את הפקדים הדינמיים גם נחלק לשני סוגים:

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

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

2. פקד לא מאוגד - לא מאוגד לשדה כלשהו בטבלה.

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

התוית ותיבת הטקסט הם מן הסתם הפקדים הנפוצים ביותר.

במקום השלישי והמכובד, נמצאת התיבה המשולבת (ComboBox)

בשונה מתיבת טקסט פשוטה, התיבה המשולבת מאפשרת לנו לבחור ערכים מתוך רשימה מוגדרת מראש, ובכך היא:

1. מקצרת את זמן הכנסת הנתונים – כי היא יכולה להשלים את הטקסט באופן אוטומטי.
2. מוודאת את תקינות הנתונים שהכנסנו – כי היא מאפשרת ערכים מוגדרים מראש, כנ"ל.
3. מאפשרת לנו להציג באלגנטיות את הנתונים בצורה קריאה, עבור שדות מפתח.

היתרונות האלו משדרגים את חווית המשתמש באופן מהותי.
בואו נראה.

פתחו את טבלת התרומות Donation בתצוגת עיצוב. עברו לשדה DonorID, ולמטה במפייני השדה שלו, בחרו בלשונית "בדיקת מידע":

נבחין כי כרגע השדה מוגדר כתיבת טקסט. אם נקליק עם הסמן על השורה, נראה בצד שמאל שלה חץ קטן למטה, נלחץ עליו ונבחר מהרשימה את התיבה המשולבת:

נקבל שלל של אפשרויות חדשות!
הכניסו את הערכים הבאים, כפי שהם מופיעים בתמונה:

שימרו את הטבלה ועיברו לתצוגת גליון נתונים. בשורה הראשונה, כנסו לשדה של DonorID ותבחינו כי יש חץ קטן למטה בסוף השדה. זה מציין כי השדה מוצג כתיבה משולבת. לחצו על החץ:

אקסס תציג לנו את שם התורם המלא ליד המזהה שלו!

איך זה קרה?
בואו נחזור על מה שעשינו:

א. שינינו את מאפייני השדה כך שיציג תיבה משולבת במקום תיבת טקסט רגילה.
ב. הגדרנו את מקור השורה של התיבה המשולבת להיות השאילתא qryDonor_FullName שכזכור, מציגה את שם התורם המלא לצד המזהה שלו.
ג. הגדרנו את מונה העמודות ל-2, כך שיוצגו שתי העמודות הראשונות בשאילתא.

כעת שימו לב שבהגדרות התיבה המשולבת, מוגדרת העמודה המאוגדת להיות מספר 1:

העמודה המאוגדת היא הערך האמיתי שנשמר בשדה שבטבלה. במקרה שלנו, העמודה הראשונה של השאילתא qryDonor_FullName היא המספר המזהה-ID של התורם (ולא השם המלא-FullName)

מה שמביא אותנו לשלב הבא:
בואו נסתיר לגמרי את המזהה של התורם!

כנסו שוב למאפייני השדה של DonorID, והפעם, הוסיפו במאפיין "רוחב עמודות" את הטקסט הבא 4;0:

כך אנו מגדירים את רוחב העמודות שיוצגו בתיבה המשולבת (משמאל לימין). דהיינו:
עמודה מספר 1 תוצג ברוחב 0 ס"מ (=מוסתרת)
עמודה מספר 2 תוצג ברוחב 4 ס"מ
שימרו את הטבלה ועברו לתצוגת גליון נתונים. שימו לב שעכשיו מוצגים שמות התורמים בלבד, ללא המזהה שלהם:

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

ראיתם כמה שזה קל וברור! זוהי העוצמה שבתיבה המשולבת. הנה כל היתרונות שציינתי בהתחלה:

1. מקצרת את זמן הכנסת הנתונים – ברור.
2. מוודאת את תקינות הנתונים שהכנסנו – נסו להקליד שם תורם שלא קיים...
3. מאפשרת לנו להציג באלגנטיות את הנתונים בצורה קריאה, עבור שדות מפתח - כמו שציינתי, למרות שהערך המוצג הוא שם התורם, הנתון שמאוחסן בפועל בטבלה הוא המזהה של התורם (ID).

מקווה שהכל היה ברור. מעכשיו התיבה המשולבת תהיה הפקד החביב עלינו.

שיעורי בית:

1. צרו שאילתא חדשה: qryFamily_FullName ובה שני שדות: המזהה של המשפחה ID, ושדה מחושב FamilyFullName שמחבר את שם המשפחה, שם האב, וא"ו החיבור ושם האם, כך שתתקבלנה התוצאות הבאות:

ID FamilyFullName
1 ראובני אברהם ושרה
2 שמעוני יצחק ורבקה

וכו'.

2. בטבלה Family_Donor שנו את הגדרות השדה FamilyID כך שיציג (בתיבה משולבת) את שם המשפחה המלא במקום את המספר FamilyID (השתמשו כמובן בשאילתא שהכנתם בסעיף א), ואת הגדרות השדה DonorID כך שיציג את שם התורם.

בהצלחה רבה!

בפוסט הבא נציג אי"ה את הפתרונות (גם לשיעור שעבר).

חלק יב: רשימת הנתמכים

בואו נראה מה עשינו עד עכשיו.

יש לנו מערכת שיכולה לנהל מאגר תורמים.
לכל תורם יש רשימת תרומות וכן יומן התקשרויות.
אני יודע לסכם את כל התרומות שהתקבלו לפי תורם.

כעת אני רוצה לעבור לצד השני של הנתמכים.

אני רוצה לנהל מאגר של משפחות נתמכות, ולייעד אליהם את התרומות שהתקבלו.

אבל יש לי כמה כללים:

1. לכל משפחה במערכת, אני רוצה לנהל רשימה של תורמים פוטנציאליים, שנראה לי שהם יתחברו למקרה שלה, ויהיו מעוניינים לתרום לה, כך שעבודת השנור שלי תהיה יותר ממוקדת.

2. התורם הנדיב, בבואו לקיים מצווות צדקה, יוכל לבחור מתוך שתי אפשרויות של תרומה:

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

נשמע מורכב? בואו נתחיל עם מה שכבר אנו יודעים.

ניצור טבלה חדשה עבור המשפחות, עם השדות הבאים:

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

שימו לב, ששדה תיאור המקרה מוגדר כטקסט קצר. ולכן הוא מוגבל עד 255 תווים. לכאורה טיפוס הנתונים העדיף לשדה זה היא "טקסט ארוך". באופן כללי אני נמנע מלהשתמש בטיפוס הנתונים הזה באקסס.

למה?

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

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

נשמור את הטבלה בשם Family.

עכשיו יש לנו בעיה.

איך מגדירים את קשרי הגומלין בין המשפחות לתורמים?

אחרי ההתבוננות, נשים לב כי לכל תורם יכולות להיות כמה משפחות קשורות, אז לכאורה זה קשר של יחיד-רבים... אבל גם לכל משפחה יכולים להיות כמה תורמים קשורים!

אחרי עוד קצת עיון , נראה שהדרך לשמור את הנתונים על הקשרים בין התורמים למשפחות, היא על ידי רשימה של זוגות:

משפחה-תורם.
משפחה-תורם.
משפחה-תורם.

לקשר הזה קוראים קשר של רבים לרבים. והדרך ליישם אותו בבסיס הנתונים היא על ידי טבלת עזר, או טבלת זוגות.

צרו טבלה חדשה עם השדות הבאים:

נסו לשמור את הטבלה בשם: Family_Donor... אקסס תקפיץ לכם את החלון הבא:

מה קרה?
אקסס דואגת לנו שנעבוד נכון!

לא הגדרנו שדה מזהה בטבלה, ואקסס מתריעה על כך.

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

הנכון הוא לקבוע כי שתי השדות גם יחד הם שדה המפתח של הטבלה. הגדרה כזו נקראת מפתח מרוכב (Composite Key)

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

עכשיו נלחץ בתפריט על הסמל של המפתח הראשי, ונבחין כי נוסף סימון של מפתח לפני שתי השורות:

מעולה. עכשיו נוכל לשמור את הטבלה בשלווה, בלי שום התראות מאקסס.

נעבור כעת להגדרת קשרי הגומלין, ונוסיף את הטבלאות החדשות Family, Family_Donor למשטח העבודה.
נגדיר את קשרי הגומלין לפי התמונה הבאה:

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

שיעורי בית
צור שני טפסים חדשים, אחד עבור המשפחות, ואחד עבור טבלת הזוגות.

בפוסט הבא ניצור את הטפסים המתאימים לניהול הטבלאות שהוספנו.

חלק י: שיעורי בית

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

1. הוסף מיון לשאילתת השמות, כך שהיא תציג את שמות התורמים לפי סדר הא"ב.
2. הוסף לשאילתת הסיכום גם שדה בשם DonationCount שיכיל את מספר התרומות של כל תורם. דהיינו עבור אברהם יופיע 3, ליצחק יופיע 1, וליעקב יופיע 0 בדוגמא שלנו.
3. סדר את שאילת הסכומים לפי סכום התרומות בסדר יורד, כלומר שבשורה הראשונה יופיע התורם שתרם הכי הרבה.
4. אני רוצה לשמור עבור כל תורם את פרטי ההתקשרות עמו. כלומר שעבור כל תורם יהיה יומן שיחות עם תאריך השיחה ותקציר השיחה. צור טבלה חדשה בשם DonorConversation כדי לנהל את פרטי ההתקשרות. חשוב: אילו שדות אמורים להופיע בטבלה?
5. צור קשר גומלין מתאים בין טבלת התורמים לטבלת השיחות.
6. צור טופס חדש בשם frmDonorConversation שמציג את פרטי ההתקשרות.
7. הטמע את הטופס הנ"ל בטופס התורמים הראשי, כך שליד רשימת התרומות תוצג גם היסטוריית השיחות.

בהצלחה לכולם!
בפוסט הבא נציג את הפתרונות בע"ה.

למייקרוסופט יש מסורת של שנים רבות ולפיה הם מתנדנדים בין מערכת הפעלה טובה או מצויינת לבין כזו שהיא אכזבה, לדוגמא:
Windows 95 היה נהדר,
Windows 98 היה שיפור לא משמעותי במיוחד,
Windows 98 SE היה שיפור גדול מאוד,
Windows Millenium היה נוראי,
Windows XP היה טוב,
Windows Vista היה קטסטרופה,
Windows 7 היה מצויין,
Windows 8.x היה אכזבה גדולה,
Windows 10 היה ועדיין - מצויין,

השמטתי כאן את מערכות NT או SERVER, וגם את Windows 2000 שהיה אחד המצויינים ביותר בעיני (באורח לא מפליא הוא התבסס על NT).

לכן אני לא ממהר לקפוץ ל-Windows 11. מחכה ל Windows 12...

חלק טו: שדרוג התרומות

קודם כל פתרונות:

1. הוסיפו שדה חדש לטבלת התרומות, בשם: TargetFamilyID, שיכיל את המזהה של המשפחה שעבורה מיועדת התרומה.
2. קיבעו את ערך ברירת המחדל לשדה זה להיות NULL במקום 0.

פתרון:

(למתבוננים: מדוע?)

כי אין משמעות לערך 0. הרי מעולם לא תהיה משפחה עם ID 0, לכן יותר מדוייק להקצות את NULL, שפירושו: כלום.

הערה: גם אם אקסס לא מאפשרת ערך 0 בשדה מספור אוטומטי, והוא תמיד מתחיל מ-1, יש מערכות DB שמאפשרות ליצור שדה מספור אוטומטי שמתחיל מ-0 (או אפילו מערך אחר). במקרה כזה הנתונים שלנו עלולים להטעות אותנו!
גם לגבי פונקצית ספירה Count, שדה המכיל ערך 0 - נספר, בעוד שדה המכיל NULL - לא נספר.

בתור פרקטיקה טובה, נשתמש בכלל הבא:
בכל מקום שאין משמעות לערך ברירת המחדל 0, נעדיף את NULL.

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

3. הגדירו את קשרי הגומלין עבור שדה זה.

פתרון:

יש לנו הרבה עבודה היום, אז קדימה:

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

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

הנה הטופס החדש, שימו לב לשדה של משפחת הייעד:

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

נשמור את הטופס החדש בשם frmDonationCard.

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

את הטופס השני נשמור בשם: frmDonationList.

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

השגיאה נוצרה כי מחקנו את הטופס frmDonation, שהופיע כטופס משנה בטופס התורם, ואקסס לא מוצאת אותו.

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

בואו נתקן את הבעיה. נעבור לתצוגת עיצוב (אקסס שוב תתריע על השגיאה. נלחץ אישור)
נבחר את פקד טופס המשנה:

ובמאפיינים, נשנה את אובייקט המקור של הפקד להיות frmDonationList:

שימו לב שקישור שדות האב עדיין מכיל את הערך ID, וקישור שדות הצאצא עדיין מכיל את הערך DonorID:

הערה חשובה: אני מקווה שחלקכם מרימים גבה ושואלים:
כיצד יתכן שטופס המשנה יהיה מקושר על ידי השדה DonorID? והלא מחקנו את הפקדים של DonorID מטופס המשנה!
שאלה מצויינת!
התשובה היא, שלמרות שמחקנו את הפקדים מן הטופס - לא מחקנו את השדה DonorID עצמו.
הטופס מכיל את ערכי כל השדות של הטבלה שעליה הוא מבוסס, גם אם הוא אינו מציג את כולם.
הפקדים משמשים רק לתצוגה של השדות, ומחיקת פקד מאוגד אינה מוחקת את השדה שאליו הוא מאוגד, בדיוק כמו שסגירת התריס אינה מסירה את השמש מן הרקיע.

נעבור לתצוגת טופס ונראה שהכל תקין:

נסגור ונשמור.

עדיין חסרה לנו פונקציה עיקרית וחשובה.

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

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

נתחיל באפשרות א:
רצינו שכל תורם יוכל לשייך את תרומותיו רק אל המשפחות המשוייכות אליו, וכרגע מוצגות לכל תורם כל המשפחות הקיימות.
לשם כך אנחנו רוצים לסנן את התיבה המשולבת של TargetFamilyID שבטופס המשנה frmDonationList, כך שתציג רק המשפחות המשוייכות לתורם הנוכחי בטופס האב frmDonor.

אבל קודם כל, נפתח את הטופס frmFamily_Donor ונמלא קצת יותר נתונים:

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

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

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

• ID, FamilyFullName מתוך השאילתה qryFamily_FullName
• DonorID מתוך הטבלה Family_Donor

לשם כך ניצור שאילתת עזר, שמצרפת את שתי הטבלאות הנ"ל.

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

יצירה > עיצוב שאילתה > ונבחר להציג את הכל:

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

עובדה מעניינת:
למרות שבשנת 2017, כשאקסס הגיעה לגיל המופלג של 25 שנה, מייקרוסופט הודיעו קבל עם ועדה כי הם מתכוונים לזנוח סופית את אקסס, (ואף קבעו לה תאריך פטירה), בשקט אלגנטי הם שינו את דעתם, הוציאו גרסאות חדשות בשנים 2019 ו-2020, ועדיין ממשיכים לעדכן את אקסס.

נחזור לענייננו.
נוסיף למשטח העבודה את הטבלה Family_Donor, ואת השאילתא qryFamily_FullName.
נגדיר את הצירוף הפנימי בין השדות ID ו-FamilyID, ונוסיף לשאילתא את השדות לפי הסדר הבא:

1. ID
2. FamilyFullName
3. DonorID

נעבור לתצוגת עיצוב ונראה שליד כל משפחה מופיעה גם עמודת התורם המשוייך אליה:

מעולה.

נשמור את השאילתה בשם: qryFamily_FullName_Donor.

שלב ב: החלפת מקור השורה של התיבה המשולבת בטופס המשנה
נפתח את טופס המשנה qryDonationList בתצוגת עיצוב, נסמן את התיבה המשולבת של משפחת הייעד, ובמאפיין מקור שורה נמחק את הכתוב לגמרי, כך:

כעת נלחץ על שלושת הנקודות משמאל למקור השורה:

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

כעת לשלב המכריע:

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

• בחלונית שנפתחה, נבחר מצד ימין את הקובץ של אקסס שלנו > Forms > כל הטפסים > frmDonorCard. (טופס האב)
• מקטגוריות הביטויים נבחר את ID. (מזהה התורם)
• ומתוך ערכי הביטויים נקליק פעמיים על "<ערך>" (הפריט הראשון)

אקסס תבנה עבורינו את הביטוי הבא: [Forms]![frmDonor]![ID]

להלן ממוספרים כל שלבי התהליך:

נלחץ על אישור ונסגור את עורך השאילתות.
שימו לב לקריטריון שנוסף לעמודה DonorID:

הנתיב [Forms]![frmDonor]![ID] מציין את השדה ID בטופס frmDonor.

פירוש הדבר הוא שאקסס תסנן עבורנו את תוצאות השאילתא, ותציג רק את הרשומות שבהם DonorID זהה לשדה ID שמופיע בטופס frmDonor.
יתר על כן, אקסס תדאג לכך שכל פעם שערך השדה ID ישתנה בטופס האב (דהיינו כשנציג תורם אחר) - השאילתה תרוץ מחדש, תעדכן בטופס הצאצא את התיבה המשולבת המבוססת על השאילתא הזו, ותספק לנו נתונים עדכניים לתורם החדש.

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

כעת נסגור את עורך השאילתות, על ידי האיקס למעלה:

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

נבחר כן.
נסגור את תצוגת העיצוב של הטופס, ונשמור כמובן את השינויים שעשינו בו.

נפתח את טופס האב frmDonor, ונראה לאילו משפחות ניתן כעת לשייך את התרומות של כהן אברהם:

נשים לב שאלו המשפחות המשוייכות אליו בטבלה Family_Donor:

נעבור ללוי יצחק, ונראה שאצלו קיימות 3 משפחות אפשריות, כי אקסס עידכנה את התיבה המשולבת עבורו:

זו בדיוק הפונקציונאליות שביקשנו!

אבל היתה עוד אפשרות:

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

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

המשימה הושלמה בהצלחה!

ננוח קצת, כי כבר עלו בדעתי שתי בעיות שעלולות לצוץ במערכת שלנו.

אולי אתם כבר יודעים? (אם כן, ציינו בתגובות)

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

עד כאן להיום, שבת שלום!

@ivrtikshoret תגדיר מה זה נקרא לפרוץ:

(לא משנה ע"י מה ומי)

אפשר לפרוץ לחדר של השרת ולשפוך עליו מים, לנתק את החשמל, לגייס כמה מיליארדים של סינים שיפציצו את האתר בבקשות? גם פצצת אטום נחשב?

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

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

פרק כג: עושים סדר: חלק ב: שדרוגים שונים, פונקציונאליות לחצני רשומה, ורגע למחשבה.

תזכורת:

בפרק הבא ניצור גם את טופס כרטיס המשפחה, ונוסיף פונקציונאליות ללחצנים שיצרנו היום.

גילוי נאות: בפרק זה עדיין לא נוסיף פונקציונאליות ללחצנים הנ"ל, אלא ללחצנים אחרים שניצור.

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

שינוי השם
ראשית נשנה את שמו לשם חדש: frmFamilyCard (כרטיס משפחה), שמתאים יותר לתכנית שלנו מהפרק הקודם:

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

לדוגמא, עבור משפחת אשרי, מופיע שקיימות 2 תרומות על סך כולל 300 ₪:

אבל אין שום מידע על סטטוס התרומות, מה בוצע ומה לא.

לצורך המחשת העניין, נפתח את טבלת התרומות ונשנה את הסטטוס של התרומה הראשונה ל-בוצעה:

כעת למשפחת אשרי יש 100 ₪ שבוצעו ו-200 ₪ שממתינים לביצוע, אך שאילתת הסיכום הנ"ל לא מציגה שום מידע על השינוי שעשינו כעת:

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

1. AwaitingDonationCount מספר התרומות הממתינות לביצוע (=המיועדות)
2. AwaitingDonationSum סכום התרומות הממתינות לביצוע (=המיועדות)
3. DoneDonationCount מספר התרומות שבוצעו בפועל
4. DoneDonationSum סכום התרומות שבוצעו בפועל

נתחיל ע"י פתיחת השאילתה בתצוגת עיצוב, וניצור שדה חדש בשם AwaitingDonationCount:

אבל מה תהיה הנוסחה שבה נשתמש?
יש כאן קושי מסויים, כי לחישוב השדה הזה אי אפשר להשתמש בפונקצית Count רגילה, מפני שאז נקבל את מספר כל הרשומות, ואנו מעוניינים לקבל רק את מספר התרומות שמיועדות אך לא בוצעו עדיין, דהיינו עם סטטוס=2.

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

ונרשום את הנוסחא הבאה:

AwaitingDonationCount: Sum(IIf([StatusID]=2,1,0))

הסבר: נוסחא זו מחשבת סכום לפי תנאי IIF: עבור כל רשומה, אם StatusID=2 (התרומה מיועדת), מוסיפים לסכום את הערך 1, אחרת – מוסיפים 0.

נסגור את הבונה, ונשנה את המאפיין "סך הכל" מ-"קבץ לפי" ל-"Expression", כדי להורות לשאילתה שכאן מדובר בביטוי מחושב ולא בשדה רגיל:

נעבור לתצוגת גליון נתונים ונראה כי הערך המופיע עבור משפחת אשרי הוא 1, דהיינו שיש לה תרומה אחת משוייכת:

יפה. כעת ניצור את השדה השני: סכום התרומות המשוייכות - בצורה דומה:
נוסיף שדה חדש בשם AwaitingDonationSum, אך הפעם במקום להוסיף לסכום המחושב את הערך 1, נוסיף את סכום התרומה הנוכחית ברשומה:

AwaitingDonationSum: Sum(IIf([StatusID]=2,[Amount],0))

ושוב, נשנה את סוג השדה ל-Expression.

כעת מוצג גם הסכום של התרומות המיועדות:

באופן דומה נוסיף את שתי העמודות הנותרות, עם הנוסחאות הבאות:
מספר התרומות שבוצעו בפועל: DoneDonationCount: Sum(IIf([StatusID]=3,1,0))
סכום התרומות שבוצעו בפועל: DoneDonationSum: Sum(IIf([StatusID]=3,[Amount],0))

הערה: למרות שאפשרי (ואפילו יותר יעיל), לחשב את שתי השדות האחרונים בלי להשתמש בעוד פונקציית סכום, אלא פשוט על ידי ההפרש בין שתי השדות הקודמים, דהיינו:
DoneDonationCount: TotalDonationCount - AwaitingDonationCount
לא כדאי לנו לעשות כן, כי אם נחליט אי פעם להוסיף למערכת ערך סטטוס תרומה חדש, למשל: "בוטלה" (כשהתרומה הוקלדה בטעות, או שהבנק לא אישר את ההעברה), השדה המחושב יתעלם מסטטוס זה, ועלול להציג ערך שגוי.

והנה התוצאה הסופית:

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

ונבצע את השינויים הבאים:
בתיבות הטקסט: הוספת קידומת "txt", הסרת הגבול, הקטנת הרוחב ל-3 ס"מ.
בטופס: מחיקת תיבת הטקסט והתווית של משפחת היעד, הסרת בוררי הרשומות, הסרת לחצני הניווט, שינוי הכותרת, הקטנת הרוחב ל-8 ס"מ.

התוצאה:

שמרו את הטופס בשם: frmFamily_DonationSummary.

נוסיף אותו כטופס משנה לכרטיס המשפחה, על ידי גרירה:

נעבור למאפייני פקד טופס המשנה, ונראה שאקסס לא ביצעה קישור בין נתוני טופס המשנה לטופס האב:

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

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

נבחר את אחד המאפיינים קישור שדות אב או קישור שדות צאצא, ונלחץ על שלש הנקודות:

ייפתח החלון הבא:

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

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

נסיים את העבודה על הטופס הזה:

1. נשנה את העוגן האופקי של פקד טופס המשנה ל: ימין, כך שיוצג בצמוד לפרטי המשפחה:
   
2. נסיר את השדה המזהה ID.
3. נעביר את תיבת הטקסט של CreatedOn לראש, ונשנה את המאפיין "נעול" ל-כן, והמאפיין "אפשר" ל-לא. כך נמנע מהמשתמש לבצע בה שינוי בטעות. אני גם אוהב להסיר לגמרי את הגבול מתיבות טקסט לקריאה בלבד, ולכן אעשה גם את זה.
4. נשנה את הכיתוב בתוויות.
5. נוסיף עוד שני לחצנים בכותרת, אחד בשם cmdNew לפתיחת כרטיס חדש, ואחד בשם cmdDelete למחיקת הכרטיס הנוכחי.

הנה התוצאה:

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

נפלא!

שלב ד: הוספת פונקציונאליות בלחצני כרטיס המשפחה
נבחר את לחצן יצירת כרטיס חדש cmdNew שיצרנו הרגע, ובמאפיינים בלשונית "אירוע", נבחר את האירוע: "בעת לחיצה", ונבחר את האפשרות "פרוצדורת אירוע":

נלחץ על שלושת הנקודות … אקסס תפתח את עורך הקוד, ותיצור שלד לפונקציית האירוע.

שימו לב לשם הפונקציה: הוא מתחיל בשם הפקד cmdNew, ומסתיים בסיומת Click כסימן שהפונקציה משוייכת לארוע הלחיצה של הפקד.

נרשום את הקוד הבא:

Private Sub cmdNew_Click()
    DoCmd.GoToRecord , , acNewRec
End Sub

הסבר הקוד:
בשפת VBA קיימים אובייקטים שונים.

אובייקט הוא מושג בסיסי במדעי המחשב המתאר משתנה, פונקציה, מבנה נתונים או שילוב של הנ"ל.

אחד האובייקטים הנכבדים באקסס הוא DoCmd שמאגד בתוכו פונקציות רבות ומגוונות, כגון שליטה על חלונות וטפסים.
אחת מהפונקציות שהוא מכיל היא: GoToRecord שתפקידה, כמובן, לבצע מעבר בין רשומות.
ניתן לספק לה 4 פרמטרים, וכולם אופציונאליים.

אנחנו דילגנו על שני הפרמטרים הראשונים על ידי ציון של פסיק, וסיפקנו רק את הפרמטר השלישי: acNewRec שפירושו "רשומה חדשה".

נחזור לאקסס על ידי Alt+F11, נעבור לתצוגת טופס, ונבדוק שלחיצה על הלחצן מעבירה אותנו לרשומה חדשה.
פשוט וקל!

כעת ללחצן המחיקה
נחזור לתצוגת עיצוב, נבחר כעת את לחצן המחיקה, וניצור פונקציית אירוע גם עבור ארוע הלחיצה שלו:

הפעם נרשום את הקוד הבא:

Private Sub cmdDelete_Click()
    DoCmd.RunCommand acCmdDeleteRecord
End Sub

הסבר: כאן אנו קוראים לפונקציה אחרת (באובייקט DoCmd) ששמה RunCommand, ומספקים לה פרמטר אחד: acCmdDeleteRecord, שפירושו: מחיקת הרשומה הנוכחית.

בואו נבדוק את הלחצן. נחזור לאקסס Alt+F11, נעבור לתצוגת טופס וננסה למחוק את משפחת ראובני...
אופס! אקסס תציג את הודעת השגיאה הבאה:

מה קרה? שימו לב ללשון ההודעה.

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

כיון שבהגדרת קשרי הגומלין, הגדרנו לאכוף את שלימות קשרי הגומלין בין הטבלאות, אם נמחק את משפחת ראובני רק מטבלת המשפחות, נהפוך את כל הרשומות של משפחת ראובני בטבלה Family_Donor לרשומות יתומות, כי אין להם שדה אב מתאים בטבלת Family. בסיס הנתונים יכיל נתונים לא שלמים.

אקסס דואגת שלא נגיע לידי כך, וזה דבר טוב.

אז מה עושים?

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

נפתח את עורך קשרי הגומלין ונקליק פעמיים על החץ המקשר בין הטבלאות Family ו-Family_Donor:

ייפתח חלון עורך קשרי הגומלין, ונסמן ב-V את האפשרות: מחק רשומות קשורות זו לזו בהתאם להירארכיית הקשרים:

נלחץ על אישור.
זהו.
כעת ברגע שנמחק משפחה, אם יש לה תורמים משוייכים, אקסס פשוט תמחק אוטומטית את הרשומות המתאימות גם בטבלה Family_Donor.

רגע, חושבים!
שימו לב כי הטבלה Family מקושרת בקשרי גומלין גם לטבלת התרומות Donation, וגם שם בחרנו לאכוף את שלמות הקשרים בין הטבלאות.
לכאורה זה אומר שפתרנו רק חצי בעיה, כי אם תהיה למשפחה גם תרומה משוייכת – לא נוכל למחוק אותה.

מה הבעיה, אפשר להגדיר מחדש גם את קשר הגומלין הזה, וכאשר נמחק משפחה - לאפשר לאקסס למחוק את התרומות המשוייכות אליה, לא?

אז זהו, שממש לא.
חישבו, האם באמת כדאי לנו לאפשר מחיקה של נתוני תרומות? ומה אם נרצה להוציא דו"ח על כל התרומות שעברו בעמותה שלנו? ואם נצטרך להגיש דוח למס הכנסה?!

לכן - לא ניגע בקשר הגומלין הזה. ואם יש למשפחה תרומה משוייכת - לא נאפשר מחיקה שלה בכלל.

מכאן עולה המסקנה הבאה:

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

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

המשך יבוא אי"ה...

@yossiz אמר בפיצוח קאפצ'ה:

מגניב! התוכנה הצליחה!

באותה שעה אמרו: וי לקאפצה שפגע בה @yossiz ...
ישר כח על ההסבר, זה נראה כל כך קל כשאתה מסביר את זה, וגם על הדרך למדנו על OCR ועיבוד תמונה.
מבלי לגרוע ח"ו מהשיטה הנפלאה, אני קצת מתפלא על הקאפצ'ה העלוב. יש היום דברים שאני בקושי מצליח לפענח (אולי אני רובוט?)

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

המערכת שלנו בינתיים מסוגלת לכמה דברים, אבל לא מאורגנת בכלל.
נו, אז הגיע הזמן לעשות קצת סדר.

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

אז לאחר שישבתי וחשבתי, הגעתי לאפיון המופיע בסרטוט הבא:

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

אגב, את התרשים הנ"ל יצרתי בעזרת כלי נפלא בשם Draw.io. זהו כלי מדהים ליצירת תרשימי זרימה, סרטוטים ועוד, קל ונוח, עם אפשרות לעברית מלאה, וקיים בגרסא מקוונת או להורדה, והוא חינמי לחלוטין!
למי שעוקב אחרי ההדרכה, הנה הקובץ של הסרטוט

תוכלו להכניס בו שינויים כרצונכם.

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

נתחיל ברגל ימין עם צד ימין של המשפחות.
ציינתי שיש שם טופס שמציג את רשימת המשפחות.
מה אני רוצה שיראו בו?
כמובן את פרטי המשפחה, ולפי האפיון, גם את סיכום התרומות למשפחה.

לשם כך ניצור שאילתת עזר, שתקבץ את הנתונים של התרומות לפי משפחה.

שלב א: יצירת שאילתת סיכום תרומות למשפחה
נפתח שאילתה חדשה, נהפוך לשאילתת קיבוץ, נייבא את טבלת התרומות, ונגדיר את השדות לתצוגה באופן הבא:

נשמור את השאילתה בשם qryFamily_DonationSummary

שלב ב: יצירת השאילתת הבסיס לרשימת המשפחות:

השאילתה הזו תושתת על צירוף של שתי השאילתות שיצרנו:

• שאילתה א: שמות המשפחה המלאים: qryFamily_FullName
• שאילתה ב: סיכום התרומות למשפחה: qryFamily_DonationSummary.

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

להלן מבנה השאילתה:

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

תצוגת גליון נתונים .VS תצוגת טפסים רציפים

לאקסס יש שתי אפשרויות להציג רשומות מרובות בטופס יחיד:

• תצוגת גליון נתונים
• תצוגת טפסים רציפים

תצוגת גליון נתונים מציגה את הנתונים בטבלה פשוטה, בדומה לגליון אקסל. ולמרות שלעתים זה מספק, לרוב נרצה להשתמש בתצוגת טפסים רציפים, שמאפשרת גמישות רבה יותר.

בואו נראה:
נסמן את השאילתה שיצרנו, ונבחר מתפריט העיצוב: "טפסים נוספים" > "פריטים מרובים". אקסס תיצור טופס ותפתח אותו בתצוגת פריסה:

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

• כותרת עליונה: משמשת בעיקר להצגת כותרות העמודות
• פירוט: מציג את הרשומה הנוכחית
• כותרת תחתונה: בה נשתמש להצגת סיכומי העמודות

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

שלב ג: הוספת סיכום עמודות
בואו ונרחיב את החלק של הכותרת התחתונה של הטופס, על ידי גרירה מטה של הגבול:

כעת נוסיף שם שלוש תיבות טקסט לא מאוגדות, ותווית אחת עם הכיתוב "סיכום", כפי שמופיע בתמונה הבאה:

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

אבל לפני כן אנחנו חייבים לטפל בדבר חשוב.

מי אני ומה שמי?

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

בכך אקסס גורמת לי חוסר ודאות כמפתח המערכת, האם FullFamilyName מתייחס לתיבת הטקסט או לשדה בטבלה? וחוסר ודאות - זה מתכון מצוין לבעיות....

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

לדוגמא:

• לתיבת טקסט אני אוסיף קידומת "txt"
• לתווית אני אוסיף קידומת "lbl"
• לתיבה משולבת אני אוסיף קידומת "cbo" וכו'

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

לשם כך אני אשנה את שמות ארבע תיבות הטקסט המאוגדות בחלק הפירוט של הטופס, לפי הטבלה הבאה:

שם קודם	שם חדש
ID	txtID
FullFamilyName	txtFullFamilyName
TotalDonationCount	txtTotalDonationCount
TotalDonationAmount	txtTotalDonationAmount

על ידי כניסה למאפיינים של הפקד (בלשונית "אחר" או בלשונית "הכל") והוספת הקידומת "txt" לשם הפקד, לדוגמא:

הערה: יש הנוהגים להוסיף סיומת לשם הפקד (במקום קידומת) דהינו FullFamilyNameTextBox וכו', זה בהחלט אפשרי, אך לטעמי מסורבל יותר. והבוחר יבחר.

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

סיימתם?
כעת נוכל לבנות את הנוסחא לסיכום העמודות, נתחיל עם עמודת שמות המשפחה, שם אנו רוצים להציג את מספר המשפחות בטופס. נבחר את תיבת הטקסט שבכותרת התחתונה של העמודה של שמות המשפחה:

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

הקלידו בבונה את הנוסחה הבאה:

Count(ID)

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

Sum(TotalDonationCount)

ובתיבה האחרונה את הנוסחה:

Sum(TotalDonationAmount)

שנו גם את תבנית העיצוב של תיבה זו ל"מטבע":

שלב ד: קצת קוסמטיקה:

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

בחרו את כל הפקדים בכותרת התחתונה, ושנו את סגנון הרקע לשקוף, ואת צבע הכתב לשחור, עם סגנון מודגש:

לחצו על הפס האפור שעליו כתוב "כותרת תחתונה בטופס", והגדירו את צבע הרקע לתכלת:

שנו גם הכותרת הראשית ואת תוויות הכותרת של העמודות לעברית.

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

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

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

אקסס תיצור לחצן עם השם "פקודהXX" ותפתח את אשף לחצני הפקודות, שאליו נסרב להתייחס ופשוט נסגור אותו בנימוס, על ידי לחיצה על "ביטול":

האשף הנ"ל מציע ליצור עבורנו פקודות מאקרו לבניית הפונקציונאליות של הלחצנים, אך אנו נכתוב זאת בעצמנו על ידי קוד VBA בהמשך.

נשנה את שם הלחצן ל cmdNewFamily ואת הכיתוב עליו ל"משפחה חדשה":

נוסיף עוד שני לחצנים בחלק הפירוט של הטופס, אחד מימין בראש השורה, בשם cmdOpenFamilyCard ועם הכיתוב "הצג", ואחד משמאל בסוף השורה בשם cmdDeleteFamily עם הכיתוב "מחק":

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

כשנסיים, נשמור את הטופס בשם frmFamilyList.

והנה הטופס המוכן, אחרי עוד כמה קנעטשים:

בפרק הבא ניצור גם את טופס כרטיס המשפחה, ונוסיף פונקציונאליות ללחצנים שיצרנו היום.

@כוספים-למשיח השאלה שלך היא מדי כללית ולכן @yossiz ענה לך באותו המטבע.
אם אתה רוצה לקבל תשובה קונקרטית למקרה שלך, תפרט בהרחבה, באיזו פלטפורמה מדובר? איזו פונקציונאליות צריכה להיות זמינה בתוכנה? האם זה אמור להיות פתוח לציבור הרחב או לקבוצת עובדים סגורה, ואם תמצי לומר לקבוצה סגורה, לכמה משתמשים בו זמנית?

לאחרונה ישנה עלייה בכמות הפוסטים בפורום עם שאלות בנוגע לאקסס.

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

מסתמא בשלי הסער הזה...

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

אבל בתנאי - שהשואל מוכן להשקיע ולהתאמץ, והמשיב יודע להשיב כראוי.

לפעמים ניכר מהשאלה שהשואל כלל לא מכיר את הנושא הנשאל, וזה עדיין בסדר.

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

ואם הוא לא מציין זאת בשאלתו, הוא מטעה את העונה ולרוב לא תצמח מהתשובה תועלת אמיתית אפילו עבורו.

ואם המשיב בעצמו מטעה את השואל...

חלק מתהליך הלימוד הוא לדעת היטב מה ברור לך כבר, ומה לא. גם אצל המלמד וגם אצל הלומד.

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

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

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

מן הראוי שגם השואלים ישקיעו מאמצים בהתאם.

@שואף הדוגמא האחרונה ממש מוגזמת... עוד מעט אנחנו נכתוב const והוא כבר יבנה לבד את כל האפליקציה, ולנו ישאר לרדת לסוף דעתו, או יותר גרוע - לדבג את הקוד שלו

@צבי-10 לצערי אין דרך פשוטה לעשות זאת.

בתחילת החודש (נובמבר 2021) הכריזו מייקרוסופט על אפשרות שילוב של אקסס בפלטפורמת PowerApps.

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

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

כרגע התוכנית זמינה בגרסת ניסיון למשתמשי Insider.
לפרטים: https://powerapps.microsoft.com/en-us/blog/announcing-power-apps-microsoft-access-security-mobility-new-experiences/

טרם התנסיתי באפשרות הנ"ל, אבל אני מקווה שאוכל לספק פרטים נוספים על כך בהמשך.

פרק כ: הפקת קבלות: חלק א: אפיון, קשר של יחיד ליחיד ועוד קצת VBA

אני רוצה להוסיף למערכת שלנו יכולת הפקה של קבלות לתורמים.
אני מעוניין באפיון הבא:

1. לכל תרומה תהיה רק קבלה אחת ויחידה.
2. לקבלות יהיה מספר רץ ייחודי.
3. לקבלה יהיה תאריך הנפקה.
4. אפשרות להוספת הודעת טקסט אישית על הקבלה.

לכאורה, הפתרון הפשוט הוא להוסיף עוד כמה שדות לטבלת התרומות:
ReceiptNumber
ReceiptDate
ReceiptMessage
ולמלא אותם בכל פעם שיוצרים קבלה.
למה לטבלת התרומות?
כי כל קבלה שייכת רק לתרומה אחת בלבד.

אבל אם נחשוב על כך, לפתרון זה ישנם שני חסרונות גדולים:

1. אני צריך לנהל בעצמי את המספר הרץ. וזה לא כל כך טריוויאלי. בכל הנפקת קבלה חדשה אצטרך לסרוק את כל טבלת התרומות, למצוא את הערך המקסימלי, להוסיף 1 ולהקצות אותו לקבלה החדשה. זה מסורבל.
   במקרה שיש כמה משתמשים במערכת, זה אפילו מסוכן, כי יתכן ושניהם ינפיקו בו זמנית את אותו המספר לשתי קבלות שונות...
2. גם ניהול תאריך הנפקת הקבלה יהיה רק באחריותי, ולא על ידי המערכת, כי לא אוכל להקצות ערך ברירת מחדל לשדה, שהרי אם כן, הוא ייקבע ברגע שאצור תרומה חדשה, ומסתמא תאריך הנפקת הקבלה לא תמיד זהה לתאריך התשלום. בנוסף אני עלול לשכוח למלא את הנתון, מה שיגרום לי סיבוך מיותר עם מס הכנסה...

אבל אל דאגה, יש פתרון יעיל בהרבה.

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

אנחנו נפריד בין נתוני התרומות לבין נתוני הקבלות, וניצור ביניהן יחס של אחד לאחד.

יחס של אחד לאחד קובע כי לכל רשומה בטבלה א תיתכן אך ורק רשומה אחת קשורה בטבלה ב.

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

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

• צמצום בנעילת רשומות
  כאשר משתמש עובד על רשומה מסויימת, אותה רשומה ננעלת עבור שאר המשתמשים. בהפרדת הנתונים לשתי טבלאות אנו מאפשרים עבודה על שתי הטבלאות במקביל ללא חשש.
• חיסכון בשטח אחסון
  לעתים אנו לא מעוניינים בשמירת כל הנתונים עבור כל הרשומות, אלא רק עבור חלקן.
  הפרדת הנתונים תאפשר לנו לשמור את הנתונים רק עבור הרשומות שבחרנו.
  במקרה שלנו זה לא רצוי, כי אנחנו כן רוצים ליצור קבלה עבור כל תרומה (יש כאן מישהו ממס הכנסה?) אבל ייתכנו מקרים אחרים שבהם זה שייך.
• הקטנה בצריכת משאבים
  הרבה מבסיסי הנתונים משתמשים במנגנון מטמון Cache עבור אחסון זמני של נתונים. גם בבחירת חלק מהעמודות (למשל על ידי שאילתת בחירה), לרוב ה-DB מייבא את כל השורה למטמון. הפרדת נתונים תקטין את המשאבים הנדרשים עבור כך.
  במקרה שלנו זה ממש לא קריטי, אבל תארו לעצמכם טבלה עם 200 או 300 עמודות (וכן, יש דברים כאלו), מסתמא המערכת נדרשת רק לחלק מהעמודות ברוב הקריאות ל-DB.
• יצירת טריגרים מבוססי טבלה מדוייקים יותר (מחוץ לתחום הדרכה זו)

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

אז בואו נראה כיצד עושים זאת:

ניצור טבלה חדשה עבור הקבלות, עם השדות הבאים:
DonationID – מפתח ראשי, מסוג מספר שלם ארוך. ערך ברירת מחדל Null
ReceiptNumber – מספור אוטומטי
ReceiptDate – תאריך\שעה. ערך ברירת מחדל =Now()
ReceiptMessage – מסוג טקסט קצר.

נשמור את הטבלה בשם Receipt.

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

הגדרת יחסי הגומלין
נפתח את עורך יחסי הגומלין, ונייבא את טבלת הקבלות.
כעת נגרור את שדה ID מטבלת Donation אל השדה DonationID בטבלת הקבלות, ונבחר בחלון עריכת קשרי הגומלין: "אכוף שלמות הקשרים בין הטבלאות".
שימו לב שאקסס יצרה יחס של אחד לאחד בין הטבלאות:

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

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

כעת נבחר את תיבת הטקסט של ההודעה לתורם, ובמאפיינים תחת הלשונית "אחר" נשנה את המאפיין "התנהגות מקש Enter" ל: שורה חדשה בשדה:

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

נסגור ונשמור את הטופס בשם: frmReceipt.
כעת נוסיף את הטופס כטופס משנה לטופס כרטיס התרומה: frmDonationCard, על ידי פתיחת הטופס של כרטיס התרומה וגרירת הטופס החדש לשם:

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

נעבור ללשונית "תבנית", ונגדיר את המאפיין עוגן אופקי ל-ימין, כדי שטופס המשנה יוצג בצד הנכון של טופס האב:

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

שימו לב שאקסס הקצתה את מספר הקבלה ואת תאריך ההנפקה באופן אוטומטי:

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

בדק בית
המערכת עובדת די טוב, אך יש עוד כמה שיפורים לבצע:

1. אין אפשרות ליצור קבלה מבלי להכניס ערך כלשהו. ומה אם איננו מעוניינים להוסיף טקסט אישי לקבלה?
   את בעיה זו נשאיר לכם לפתור בשיעורי הבית.

2. בטופס המשנה, לא אמורה להיות יותר מקבלה אחת עבור כל תרומה, ולכן לחצני הניווט שם מיותרים. אם ננסה להכניס יותר מקבלה אחת עבור תרומה מסויימת, נקבל שגיאה.

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

נסו לסגור את הטופס. אקסס לא תאפשר לשמור את הרשומה, ותציג הודעת שגיאה:

לחצו על אישור.
אקסס תציג את השאלה הבאה:

בחרו כן.

כתוצאה מהמהלך הזה, הנתונים שהכנסתם יאבדו. גם המספר הרץ של הקבלות יקפוץ על המספר 2, והקבלה הבאה תקבל את המספר 3, כי המספר 2 כבר "שרוף" במחיקת הרשומה השגויה.

פתרון לבעיה
כדי להימנע מלהיכנס בכלל למצב שכזה, נבצע כמה שינויים.
אנו מעוניינים לחסום אפשרות להוספת קבלה לתרומה שיש לה קבלה קיימת. לשם כך נשתמש במאפיין "אפשר תוספות" או באנגלית "AllowAdditions" של הטופס. כאשר מאפיין זה מכיל ערך True, ניתן להוסיף רשומות. וכאשר הוא מכיל את הערך False, אין אפשרות להוסיף רשומות.

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

הקלידו את הקוד הבא:

Private Sub Form_Current()
    If Me.frmReceipt.Form.Recordset.RecordCount = 0 Then
        Me.frmReceipt.Form.AllowAdditions = True
    Else
        Me.frmReceipt.Form.AllowAdditions = False
    End If
End Sub

הקוד הנ"ל בודק את מספר הרשומות בקבוצת הרשומות של טופס המשנה (שורה 2), ואם הוא שווה 0 (=אין קבלה), אז קובע את ערך המאפיין AllowAdditions בטופס המשנה ל-True, וכך מאפשר הוספת רשומה חדשה (שורה 3), אחרת, הוא קובע את המאפיין ל False, ובכך חוסם את האפשרות (שורה 5).
סגרו ושמרו.

עדיין יש כאן פתח לשגיאות, כי כאשר ניצור תרומה חדשה, המאפיין AllowEditions בטופס המשנה יהיה על True, ונוכל להכניס עוד תרומה. עלינו לדאוג להעבירו למצב False לאחר ההוספה. לשם כך נשתמש בפונקציה נוספת שנצמיד כמובן לארוע "לאחר הוספה" של טופס המשנה.
פתחו את טופס המשנה frmReceipt בתצוגת עיצוב, וצרו פונקציה עבור הארוע "לאחר הוספה":

הקלידו את הקוד הבא:

Private Sub Form_AfterInsert()
    Me.AllowAdditions = False
End Sub

חיזרו לטופס על ידי הקשה על Alt+F11, עיברו ללשונית תבנית, והסירו את לחצני הניווט מהטופס, הם מיותרים כעת:

תוספת: הכינוי Me
כדי לגשת לטופס הפתוח אנו משתמשים במילה השמורה Me. המילה Me היא כינוי למופע של מחלקת הטופס שהפעיל את האירוע.

מה הפשט?

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

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

בשפת תכנות, לתבנית קוראים בשם מחלקה (או מודל). ולצורות שיוצרים ממנה קוראים מופעים.

כל מופע מכיל את כל הפונקציונאליות והמאפיינים של המחלקה שממנה נוצר.

אם נחשוב על כך, כל טופס יכול באופן עקרוני להיות פתוח בו זמנית כמה וכמה פעמים.
נתאר לעצמנו מצב דמיוני שבו הטופס פתוח ב-10 מופעים. כאשר נסגור מופע אחד, אותו מופע יפעיל את הארוע "סגירת טופס", אפילו שתשעת המופעים האחרים פתוחים. כיצד נדע מתוך הקוד, איזה מופע של הטופס נסגר?

לשם כך שפת VBA מספקת לנו את המאפיין Me ככינוי שבאמצעותו ניגשים ישירות למופע הפעיל של הטופס שהריץ את הקוד.
או אם תרצו: אם אין אני לי – Me לי.

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

1. צרו טבלה חדשה בשם DeliveryMethod שתכיל שדה מזהה ID ושדה נוסף בשם Description.
   טבלה זו תכיל את אפשרויות השליחה של הקבלה, כאשר 1 מציין שהקבלה תישלח בדואר רגיל, ו-2 מציין כי הקבלה תישלח בדואר אלקטרוני.

2. הוסיפו שדה נוסף לטבלת הקבלות בשם DeliveryMethodID מטיפוס מספר ארוך. הערכים לשדה זה יילקחו מהטבלה בסעיף א, על ידי תיבה משולבת. קבעו את ערך ברירת המחדל של השדה ל-Null.

3. בטבלת הקבלות, הפכו את כל השדות לנדרשים, למעט השדה של ההודעה האישית.

4. הוסיפו פקד תיבה משולבת עבור השדה הנ"ל בטופס הקבלה.

חלק י"ז: פתרון (חלקי) לבעיית שיוך התרומות

נתחיל דווקא מהבעיה השניה:

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

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

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

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

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

עברו לתצוגת גליון נתונים והכניסו את השורות הבאות:

נפתח את הטבלה Donation ונוסיף שדה חדש StatusID מטיפוס מספר שלם ארוך. ונקצה לו ערך ברירת מחדל 1 (כלומר סטטוס=זמינה):

גם כאן, נעצב את התצוגה של השדה להראות תיבה משולבת, כך שיוצג התיאור של הסטטוס במילים ולא ע"י מספר:

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

יפה.

בואו נפתח את טבלת התרומות בתצוגת גליון נתונים, ונראה כי השדה נוסף וברירת המחדל היא "זמינה":

אבל,שימו לב כי עבור התרומות שכבר קיימות במערכת, השדה ריק. מדוע? כי באקסס, כאשר מגדירים ערך ברירת מחדל לשדה, ההגדרה תקפה רק עבור רשומות חדשות שיתווספו מעתה, ולא מעדכנת עמודות ישנות.

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

שלב ב: עדכון שדה הסטטוס עבור הרשומות הקיימות

דקה למחשבה:

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

בדוגמא שלנו יש רק 4 שורות, ונוכל לעבור שורה שורה באופן ידני ולשנות אותה.
אבל בדרך כלל, לא נעשה כן.
מה יקרה אם יש 40 שורות? ואם יש 4000? ואם בטעות נסמן סטטוס "בוצעה" לתרומה לא משוייכת? צריך מנגנון שיעשה זאת באופן אוטומטי ונטול טעויות. לשם כך נכיר סוג נוסף של שאילתא:

שאילתת עדכון
יצירה > עיצוב שאילתא > הוסיפו את טבלת התרומות, ומתוכה את השדה StatusID לרשימת השדות למטה. כעת בחרו סוג שאילתה "עדכן" מהתפריט:

שימו לב שנוספה כותרת שורה: "עדכן ל:"

בשדה זה אנו אמורים לציין את הערך המעודכן של השדה StatusID. אבל כפי שציינתי, ערך זה תלוי:

• אם התרומה לא משוייכת למשפחה, אנו רוצים שערך השדה יתעדכן למספר 1 (=זמינה)
• אחרת, השדה יתעדכן למספר 2 (=מיועדת)

יש יותר מאפשרות אחת לעשות כן. היום נשתמש בפונקצית התנאי הכפול IIF
פונקצית התנאי IIF מקבלת שניים או שלושה פרמטרים, ומחזירה ערך לפי ההגיון הבא:
אם ערך הפרמטר הראשון הוא אמת – יוחזר ערך הפרמטר השני. אם לא – יוחזר ערך הפרמטר השלישי (אם צייננו פרמטר שלישי. אחרת יוחזר NULL)
כנסו לשדה ופתחו את הבונה, ושם כתבו את הנוסחא הבאה:
IIf([TargetFamilyID] Is Null, 1, 2)

חשוב מאד: שימו לב להוסיף את הסוגריים המרובעות מסביב לשם השדה TargetFamilyID, אחרת אקסס תפרש אותו בתור מחרוזת, ותוסיף לו גרשיים, והתוצאות יהיו שגוייות, כי התנאי בפרמטר הראשון תמיד יחזיר שקר.
זהו.
כל מה שנדרש זה פשוט להריץ את השאילתה.
בחרו מהתפריט למעלה: "הפעל". אקסס תשאל האם אתם בטוחים שברצונכם לעדכן 4 שורות:

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

נחשוב: האם אנו צריכים לשמור את השאילתה? כנראה שלא. אנו לא אמורים לשנות באופן גורף את ערך השדה בעתיד.

נבחר "לא".
נפתח את טבלת התרומות ונבדוק שכל הרשומות עודכנו בצורה נכונה:

נראה מצוין!
רבע שעה הפסקה ונמשיך.

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

שמרו את הטבלה ביציאה ממעצב הטבלה. אקסס תציג את ההודעה הבאה:

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

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

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

שלב ד: הוספת שדה הסטטוס לטופס רשימת התרומות ונעילתו
אנו רוצים להציג למשתמש את הסטטוס של כל תרומה. נפתח את הטופס frmDonationList בתצוגת עיצוב, ונבחר מהתפריט למעלה: "הוסף שדות קיימים":

אקסס תציג את כל השדות בטבלה שעליה מבוסס הטופס, דהיינו טבלת התרומות Donation. נגרור את השדה StatusID לתוך הטופס, לפני שדה משפחת הייעד:

כעת ננעל את השדה לשינויים:
נעבור לתצוגת המאפיינים של השדה על ידי מקש F4, ובלשונית נתונים נשנה את ערך המאפיין נעול ל-כן:

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

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

ובתיבת הביטוי הקלידו [StatusID] <> 1

נסמן את האפשרות הפוך לזמין, ונשים לב כי התצוגה המקדימה מראה פקד אפור (=לא זמין)

נבחר אישור פעמיים כדי להחיל את כלל העיצוב שיצרנו.

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

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

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

צרו שאילתת עדכון חדשה, והוסיפו למשטח העבודה את טבלת התרומות.
הוסיפו לרשימת השדות למטה את שני השדות StatusID ו- TargetFamilyID.
כעת השלימו את הפרמטרים כפי שמופיע בתמונה:

הגדרה זו פירושה:
עדכן את השדה StatusID כאשר הוא מכיל את הערך 1 (=זמינה) וגם שדה משפחת היעד אינו ריק.
לשם שעשוע, עברו לתצוגת SQL וראו את תחביר השאילתה:
UPDATE Donation SET Donation.StatusID = 2 WHERE (((Donation.StatusID)=1) AND ((Donation.TargetFamilyID) Is Not Null));
המילה UPDATE מציינת כי ברצוננו לעדכן את הטבלה Donation. הפקודה SET… פירושה קבע את שדה Donation.StatusID לערך 2. המילה WHERE מציינת את התנאי לעדכון, והמילה AND מציינת כי שני חלקי התנאי צריכים להתקיים. פשוט, לא?

שמרו את השאילתה בשם: qryUpdate_SetDonationStatusToTargeted.

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

כדי להריץ את השאילתה, נלחץ עליה פעמיים. אקסס תשאל האם עשינו זאת בכוונה:

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

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

אנחנו מתקדמים.

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

1. להריץ את שאילתת העדכון כשהדבר מתבקש, למשל עם סגירת הטופס. (ככל הנראה לא יהיה מנוס משימוש ב-VBA למרות הכל...)
2. לאפשר שינוי הסטטוס ל"בוצעה" במקרה שאכן התרומה הועברה למשפחה.
   נשאיר זאת לפעם הבאה.

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

1. לא מוצג שדה הסטטוס.
2. אנו מעוניינים לאפשר למנהל לשנות רק תרומה זמינה, ולא שכבר מיועדת או בוצעה.

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

חלק טז: מחשב מסלול מחדש

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

איפה עצרנו?

בחלק הקודם הזכרתי שיש שתי בעיות במערכת שיצרנו.

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

מה שמוביל אותי לבעיה השנייה והעקרונית:

2. האם בכלל אפשר להעביר תרומה ממשפחה אחת לאחרת? כל זמן שהתרומה לא בוצעה בפועל, כלומר שהתורם העביר למערכת את הכסף, אך אנחנו עדיין לא העברנו אותו למשפחה – ייתכן ונרצה לאפשר לשנות את הייעוד. אבל אם התרומה כבר הועברה למשפחה, אסור שתהיה אפשרות לשנות את הייעד.

אל תדאגו, יש פתרון לבעיות הנ"ל, חשבתי אפילו על כמה.

אז מה עושים?

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

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

זו האופציה הכי קלה. החיסרון הגדול שלה הוא שאם בחרנו בטעות משפחה לא נכונה – השדה יינעל ולא נוכל לשנות את הייעד. נצטרך למחוק את הרשומה וליצור חדשה.
נוכל לשפר את האפשרות הזו על ידי אפשרות פתיחת הנעילה על ידי הקשת קוד מנהל.
אבל נצטרך להשתמש בקוד VBA (או במאקרו רח"ל) - ואין לנו עדיין שום הכירות עם התחומים האלו.
מה נעשה, נתפשר על נעילה וזהו?
במחשבה שניה זה לא נורא, בטופס של כרטיס התרומה הרי לא ננעל את שדה משפחת היעד, כך נוכל לשנות אותה אם נרצה.
רגע, ואם נשנה בטעות?
אוף!

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

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

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

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

קצת כואב לי שכל העמל של החלק הקודם ירד לטמיון. אבל לכאורה זה הפתרון הכי טוב.
אבל הוא דורש ידע בכתיבת קוד VBA, שלעת עתה אין לנו. אולי נעזוב הכל ונתחיל ללמוד VBA?
וואו. כואב לי הראש.

כל השקלא וטריא הזו מעלה נקודה מאוד חשובה.

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

תשבו ותתכננו עם דף ועפרון:

1. מה המטרות של המערכת
2. אילו ישויות קיימות בה (תורמים, משפחות, נציגים, מנהלים, וכו' וכו')
3. סרטטו על דף סקיצה כללית של המסכים השונים
4. מה הפונקציונאליות שתתאפשר למשתמש בכל מסך

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

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

@ארכיטקט הבנתי שהדברים מתובלים כהרגלך בהומור וציניות, ואחר בקשת המחילה, אני חושב שזו הצהרה מעט יומרנית.

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

אני מודה על האמת, שלא רציתי בכלל להסתכל על EF בתחילה. אני לא אוהב קוד שלא אני יצרתי, אבל אני חייב לתחזק. מי הם מייקרוסופט שיקבעו לי מה לעשות, ואיך לעשות את זה?
השתמשתי רק ב-Dapper, והרגשתי נהדר למשך תקופה. עד שבסופו של דבר, ראיתי שאני משקיע המון זמן בבניה של ה-DB, עיצוב האובייקטים, migrations ("הַגִירוֹת" בלע"ז... ), מיפוי וכו'.
כשראיתי קוד של EF, זה היה פשוט וקריא בצורה מעוררת קנאה.

אגב, "המשטר הטוטאליטארי" של מייקרוסופט מאפשר הרבה גמישות, למי שבקי בנבכי ורזי EF.

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

EF הוא כלי מבוסס, וגם Dapper. לכל אחד מהם יש חסרונות או מוגבלויות. אני חושב שהצורה היותר נכונה להסתכל עליהם היא לפי התועלת שהם נותנים.
אחת הדרכים היא להשתמש ב-Dapper לקריאה מה-DB ולהרויח את המהירות בקריאה , וב-EF לכתיבה, שדורשת פעמים רבות עדכון מבוזר של נתונים בין טבלאות\ישויות שונות, והמשתמש יותר סלחני בקשר לזמן התגובה שלה.

@dovid במקרה הנ"ל (שתי סדרות עם טווחים שונים) מקובל להשתמש בגרף משולב של טורים וקוים, כאשר לכל סדרה יש ציר נפרד (ראשי ומשני) בצידי הגרף.

היה לי צורך לעשות קצת מניפולציה על התאריכים וליצור טבלת ציר, כדי להציג את הציר של הימים כראוי:

מצ"ב הקובץ: גרף משולב.xlsx

@ש-ב אני לא יודע מה הרמה שלך, אבל אם אתה מתחיל, אני יכול לספר לך מנסיוני, שללמוד את הנושאים האלו מתוך ספר, עלול לייאש אותך די מהר. ספר על HTML או CSS לעולם לא יקיף את כל הנושא כראוי, אא"כ הוא יבוא בגודל של אנציקלופדיה, וגם אז הוא לא יהיה רלונטי, CSS לבדה היא שפה ענקית וחיה שמתפתחת באופן קבוע.

מסתמא תתכוון ללמוד גם JS, וזה בכלל ספר נפרד...

מלבד זאת, ספר הוא מאוד מוגבל ביכולת ההוראה שלו. יש נושאים שבהם סרטון קצר שווה מאה תמונות ואלף מילים.

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

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

כך אני למדתי, ועדיין לומד, את הנושאים האלו.

@nigun אוקי אני מתנדב להסביר:

א. כיוון שבייצוג בינארי אפשר ע"י 10 סיביות לייצג 1024 אפשרויות (אם כל ספרה היא 0 או 1, מספר האפשרויות הוא 2 בחזקת 10 = 1024) יוצא שעל ידי 10 סיביות אפשר לקבל כל מספר בין 0 ל-1023 (שזה בעצם 1024 אפשרויות)
ב. נחלק את המטבעות כך שבכל מעטפה תהיה חזקה של 2 (כל מעטפה מייצגת סיבית אחת במספר)

מעטפה א = 1 מטבעות (2 בחזקת 0)
מעטפה ב = 2 מטבעות (2 בחזקת 1)
מעטפה ג = 4 מטבעות (2 בחזקת 2)
מעטפה ד = 8 מטבעות (2 בחזקת 3)

אם נתבונן רגע, נראה שבארבע מעטפות כבר ניתן לקבל 16 אפשרויות
0000 = 0
0001 = 1 (מעטפה א)
0010 = 2 (מעטפה ב)
0011 = 3 (מעטפות א+ב)
....
1111 = 15 (מעטפות א+ב+ג+ד)

אם נמשיך באותה הדרך, במעטפות הבאות יהיו הסכומים 16, 32, 64, 128, 256
המעטפה האחרונה תכיל רק 488 במקום 512 כי לא היו מהתחלה 1024 מטבעות, רק 1000.