בגרות במדעי המחשב תכנות באינטרנט 899372 - קיץ 2026

מה נדרש – לבחור את התיאור הנכון של האובייקט Request.

רעיון – בתקשורת לקוח-שרת הדפדפן (הלקוח) שולח בקשה (Request) לשרת, והשרת מחזיר תגובה (Response). ב-ASP.NET האובייקט Request מייצג את הבקשה שהגיעה מהלקוח: דרכו השרת קורא את הנתונים שנשלחו, למשל Request.Form["userCode"] (שדות טופס שנשלחו ב-POST) או Request.QueryString["id"] (פרמטרים בכתובת).

פתרון – התשובה הנכונה: ב.

בדיקה – למה האחרות שגויות:

טעות נפוצה: לבלבל בין Request (מהלקוח לשרת) לבין Response (מהשרת ללקוח).

מה נדרש – להחזיר עמודה אחת (songName) של השירים שמקיימים שלושה תנאים יחד.

רעיון – בוחרים רק את העמודה songName מהטבלה Songs, ומסננים ב-WHERE עם שלושה תנאים שמחוברים ב-AND (כי כל התנאים צריכים להתקיים יחד):

פתרון

SELECT songName
FROM Songs
WHERE plays > 1000 AND type = 'Pop' AND releaseYear = 2020;

בדיקה – השאילתה על טבלה קטנה לדוגמה:

התוצאה: Blinding Lights, Dynamite.

טעות נפוצה: לכתוב plays >= 1000 (כולל 1000), או לחבר את התנאים ב-OR במקום AND.

מה נדרש – לא את קוד ה-HTML, אלא את מה שהדפדפן מציג אחרי שהשרת שולח לו את המחרוזת str.

רעיון – הפעולה בונה מחרוזת HTML של טבלה (border = '1' – טבלה עם מסגרת). בכל סיבוב של הלולאה (i מ־1 עד 6) נוספת שורה (<tr>) ובה תא אחד (<td>). לכן מתקבלת טבלה בעלת עמודה אחת ו־6 שורות. התוכן של כל תא נקבע לפי התנאים, ושימו לב שהבדיקה i % 6 == 0 נעשית לפני i % 3 == 0.

פתרון – מעקב:

המחרוזת שנשלחת לדפדפן:

<table border = '1'><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>Buzz</td></tr><tr><td>4</td></tr><tr><td>5</td></tr><tr><td>Fizz</td></tr></table>

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

בדיקה – עבור num = 6 מתקבלת בדיוק המחרוזת שלמעלה; התאים לפי הסדר: 1, 2, Buzz, 4, 5, Fizz.

טעות נפוצה: לכתוב Buzz עבור 6 (כי 6 מתחלק גם ב־3) – אבל התנאי הראשון i % 6 == 0 מתקיים ולכן נכתב Fizz וה-else if לא נבדק. טעות נוספת: לצייר את התאים בשורה אחת – כל תא נמצא ב-<tr> משלו, ולכן הם מוצגים זה מתחת לזה.

מה נדרש – להשלים שישה ביטויים בפעולה שבודקת אם encryptedCode הוא הצפנה תקינה של originalCode במרווח X.

רעיון – משתמשים בשני אינדקסים:

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

פתרון

הפעולה המלאה:

function isValidCode(originalCode, encryptedCode, X)
{
    var i = 0;
    var j = 0;
    // נסרוק את שתי המחרוזות כל עוד לא הגענו לסוף שלהן
    while (i < originalCode.length && j < encryptedCode.length)
    {
        // אם התווים במיקומים המתאימים אינם שווים – הקוד אינו תקין
        if (originalCode.charAt(i) != encryptedCode.charAt(j))
            return false;

        // נתקדם בשתי המחרוזות
        i++; // i
        j = j + X; // j
    }
    // אם לא סיימנו לעבור עד סוף שתי המחרוזות – הקוד אינו תקין
    if (i < originalCode.length || j < encryptedCode.length)
        return false;

    return true;
}

הערה על כותרת הפעולה: בשאלון כתוב function isValidCode (var originalCode, var encryptedCode, var X). ב-JavaScript לא כותבים var ברשימת הפרמטרים (זו שגיאת תחביר), ולכן בפתרון הכותרת היא function isValidCode(originalCode, encryptedCode, X). אין לכך השפעה על הביטויים החסרים.

בדיקה

מעקב עבור הדוגמה הראשונה (originalCode = "ACE", encryptedCode = "ATCDE", X = 2, אורכים 3 ו־5):

בסוף: i < 3 שקר, j < 5 (6 < 5) שקר ⇐ התנאי (6) שקר ⇐ מוחזר true.

התוצאות:

הערה (דיוק): אחרי הלולאה j כבר קפץ X מקומות מעבר לתו האחרון שנבדק, ולכן הביטוי (6) לא מזהה 1 עד X−1 תווים מיותרים בסוף המוצפנת (למשל "ACE", "ATCDEF", 2 מחזיר true). בדיקה מדויקת לגמרי להגדרה היא i < originalCode.length || j - X != encryptedCode.length - 1; בבדיקה ממוחשבת של כל המחרוזות מעל {A,B} (מקור עד אורך 3, מוצפנת עד אורך 7, X מ־1 עד 4) הגרסה המדויקת נכונה תמיד, והגרסה שבתשובה שונה ממנה רק במקרים האלה.

טעות נפוצה: לקדם את j ב-1 במקום ב-X, או לבדוק בסעיף (3) שוויון (==) במקום אי-שוויון.

מה נדרש – קוד C# בצד השרת שקורא את שלושת משתני ה-Session ומפנה (Redirect) לאחד משלושה דפים.

רעיון

פתרון (בתוך Page_Load של הדף, או בתוך אירוע לחיצה על כפתור):

protected void Page_Load(object sender, EventArgs e)
{
    int age = int.Parse(Session["age"].ToString());
    bool isMember = bool.Parse(Session["isMember"].ToString());
    int visits = int.Parse(Session["visits"].ToString());

    if (age >= 18 && isMember && visits >= 10)
        Response.Redirect("proWorkout.aspx");
    else if (age >= 15 && (age < 18 || isMember))
        Response.Redirect("basicWorkout.aspx");
    else
        Response.Redirect("home.aspx");
}

בדיקה:

בכל הצירופים של גיל 10–25, מנוי/לא מנוי וביקורים 0–15 המשתמש מופנה לדף הנכון.

טעות נפוצה: לכתוב age >= 15 && age < 18 || isMember בלי סוגריים. האופרטור && קודם ל-||, ולכן הביטוי מתפרש כ-(age >= 15 && age < 18) || isMember, ומנוי בן 12 יופנה בטעות ל-basicWorkout.aspx. טעות נוספת: להשוות את Session["age"] ישירות למספר בלי המרה.

מה נדרש – פעולה בוליאנית ב-C# (צד שרת) שבודקת שני תנאים: המספר מתחלק ב־5, וסכום ספרותיו מתחלק ב־7.

רעיון

פתרון

public bool IsFizzBuzz(int num)
{
    if (num % 5 != 0)
        return false;
    int sum = 0;
    int n = num;
    while (n > 0)
    {
        sum += n % 10;
        n = n / 10;
    }
    return sum % 7 == 0;
}

בדיקה – מעקב עבור num = 455 (455 % 5 == 0, ממשיכים):

14 % 7 == 0 ⇐ מוחזר true.

התוצאות: 25 → True, 455 → True, 52 → False, 35 → False (כמו בשאלה); 70 → True, 5 → False, 160 → True. מספרי FizzBuzz עד 300: 25, 70, 95, 115, 160, 185, 205, 250, 275.

טעות נפוצה: לבדוק אם סכום הספרות מתחלק ב־5 (במקום המספר עצמו), או לחשב את סכום הספרות על num עצמו ואז לבדוק num % 5 אחרי הלולאה – כש-num כבר 0 (ו-0 מתחלק ב־5, כך שהבדיקה תמיד תצליח).

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

רעיון – הפונקציה המצרפת COUNT(*) סופרת את השורות שעברו את הסינון. התנאי "גדול מ־500 וקטן מ־800" הוא טווח פתוח – שני אי-שוויונות חזקים המחוברים ב-AND.

פתרון

SELECT COUNT(*)
FROM SongsStats
WHERE plays > 500 AND plays < 800;

בדיקה – בטבלת הדוגמה: Hello (800) – לא, כי 800 אינו קטן מ־800; Shape (600) – כן; Bad Guy (300) ו-One Dance (350) – לא. התוצאה: 1.

טעות נפוצה: להשתמש ב-BETWEEN 500 AND 800 – BETWEEN כולל את הקצוות, ואז Hello (800) נספר בטעות.

מה נדרש – ערך אחד: מספר ההשמעות ביום הגבוה ביותר.

רעיון – הפונקציה המצרפת MAX מחזירה את הערך הגדול ביותר בעמודה.

פתרון

SELECT MAX(dayPlays)
FROM SongsStats;

בדיקה – ערכי dayPlays: 500, 400, 150, 250. התוצאה: 500.

מה נדרש – שתי עמודות (songName, artist) של השירים שבהם nightPlays גדול לפחות פי 2 מ-dayPlays.

רעיון – אפשר להשוות בין שתי עמודות של אותה שורה ואף לבצע עליהן חישוב בתוך WHERE. "גדול לפחות פי שניים" פירושו nightPlays ≥ 2 · dayPlays.

פתרון

SELECT songName, artist
FROM SongsStats
WHERE nightPlays >= 2 * dayPlays;

בדיקה – בטבלת הדוגמה אף שיר אינו מקיים את התנאי (למשל Hello: 300 ≥ 1000? לא; Bad Guy: 150 ≥ 300? לא), ולכן השאילתה מחזירה תוצאה ריקה – זו התשובה הנכונה עבור הדוגמה. בטבלה מורחבת שהוספנו לה את השירים Night Song (יום 100, לילה 200) ו-Late (יום 100, לילה 250) הוחזרו בדיוק שני השירים האלה (200 = 2·100 נכלל, כי "לפחות").

טעות נפוצה: להפוך את הכיוון (dayPlays >= 2 * nightPlays) או לכתוב nightPlays * 2 >= dayPlays.

מה נדרש – סכום עמודת dayPlays על כל השורות.

רעיון – הפונקציה המצרפת SUM, בלי WHERE (כל השירים).

פתרון

SELECT SUM(dayPlays)
FROM SongsStats;

בדיקה – 500 + 400 + 150 + 250 = 1300. התוצאה: 1300.

טעות נפוצה: להשתמש ב-COUNT(dayPlays) – COUNT סופר שורות (4) ואינו מסכם ערכים.

מה נדרש – שמות השירים שמשכם מחוץ לטווח 3–5 דקות.

רעיון – "או קטן מ־3 או גדול מ־5" – שני תנאים המחוברים ב-OR (שיר לא יכול להיות גם קצר מ־3 וגם ארוך מ־5, ולכן AND היה מחזיר תמיד תוצאה ריקה). הגבולות 3 ו־5 אינם נכללים.

פתרון

SELECT songName
FROM SongsStats
WHERE duration < 3 OR duration > 5;

בדיקה – משכים: 4, 3, 5, 2. רק One Dance (2) מקיים. התוצאה: One Dance. (3 ו־5 אינם נכללים: Shape ו-Bad Guy לא הוחזרו.)

טעות נפוצה: לחבר את התנאים ב-AND (duration < 3 AND duration > 5) – שאילתה כזו מחזירה תמיד תוצאה ריקה. (לעומת זאת duration NOT BETWEEN 3 AND 5 נכון.)

מה נדרש – שמות האמנים ששמם מתחיל ב-B או ב-H.

רעיון – האופרטור LIKE עם תבנית: 'B%' פירושו "מתחיל ב-B ואחריו כל רצף תווים". שני התנאים מחוברים ב-OR. DISTINCT מונע הופעה כפולה של אמן שיש לו כמה שירים (לא חובה, אבל מתאים ל"שמות האמנים").

פתרון

SELECT DISTINCT artist
FROM SongsStats
WHERE artist LIKE 'B%' OR artist LIKE 'H%';

ב-Microsoft Access תו ה"כל רצף" הוא * במקום %: WHERE artist LIKE 'B*' OR artist LIKE 'H*'.

בדיקה – האמנים: Adele, Ed, Billie, Drake. רק Billie מתחיל ב-B ואין אמן שמתחיל ב-H. התוצאה: Billie. בטבלה מורחבת עם האמנים Halsey ו-Bruno הוחזרו Billie, Halsey, Bruno.

טעות נפוצה: לכתוב artist = 'B%' (השוואה רגילה, ללא LIKE – מחפש שם שהוא בדיוק "B%"), או LIKE 'B%' OR 'H%' בלי לחזור על שם העמודה.

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

רעיון

פתרון – הקוד להשלמה (במקום ההערה "השלימו כאן"):

    if (ds.Tables[0].Rows.Count == 0)
        Response.Redirect("notFound.aspx");
    else if (ds.Tables[0].Rows[0]["ticketType"].ToString() != Request.Form["ticketType"])
        Response.Redirect("wrongTicket.aspx");
    else
        Response.Redirect("success.aspx");

הערה על השאילתה המודפסת: במחרוזת "SELECT * FROM tickets WHERE userCode = {0}'" חסר הגרש הפותח לפני {0}. כיוון ש-userCode הוא טקסט, השאילתה הנכונה היא:

command.CommandText = string.Format(
   "SELECT * FROM tickets WHERE userCode = '{0}'",
   Request.Form["userCode"]);

בדיקה – ההשלמה עם DataSet שמולא בתוצאת השאילתה על טבלת הדוגמה:

השאילתה עצמה (עם הגרשים): עבור 'A123' מוחזרת השורה A123 | Regular, ועבור 'C999' – אין שורות.

טעות נפוצה: לגשת ל-ds.Tables[0].Rows[0] לפני שבודקים שיש שורות – כשהקוד לא קיים זו שגיאת ריצה. טעות נוספת: להשוות Rows[0]["ticketType"] (מטיפוס object) ישירות למחרוזת בלי ToString().

מה נדרש – לכתוב מחרוזת SQL ולהציב אותה ב-command.CommandText.

רעיון

פתרון

command.CommandText = "SELECT songName, plays FROM SongsStats " +
                      "WHERE dayPlays > nightPlays AND LEFT(songName, 1) = LEFT(artist, 1)";

(המחרוזת מפוצלת לשתי שורות בעזרת + רק לנוחות הקריאה; אפשר לכתוב אותה בשורה אחת.)

אותה לוגיקה בכתיב SQL אחר, שבו במקום LEFT משתמשים ב-substr:

SELECT songName, plays
FROM SongsStats
WHERE dayPlays > nightPlays AND substr(songName, 1, 1) = substr(artist, 1, 1);

בדיקה – על טבלת הדוגמה משאלה 7:

השאילתה מחזירה 0 שורות, ולכן הפעולה תדפיס Number of songs: 0. בטבלה מורחבת שהוספנו לה את Halo/Hozier (יום 600, לילה 300), Easy/Ed (יום 300, לילה 100) ו-Dreams/Drake (יום 200, לילה 300) הוחזרו Halo | 900 ו-Easy | 400 (Dreams לא, כי יש בו יותר השמעות בלילה).

טעות נפוצה: לכתוב songName LIKE artist + '%' או להשוות את השמות כולם (songName = artist) במקום את האות הראשונה בלבד; לשכוח את המירכאות סביב מחרוזת ה-SQL ואת ; בסוף שורת ה-C#.