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

@דוד-החדש כתב באקסס מבוסס SQL:

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

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

אגב, אם יש לך אפשרות להתחבר ישירות לשרת ה-SQL של הלקוח מהמחשב שלך, ולא רק דרך RDP, ל-VS יש כלים שיכולים לעזור לך לנהל גרסאות של SQL, להשוות סכמות של שני db, ליצור script של כל השינויים הנדרשים, ולהריץ אותו על ה-db הרצוי.

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

SELECT Connect FROM MSysObjects WHERE Type=4

@דוד-החדש כתב באקסס מבוסס SQL:

אבל אני קצת מפחד לעשות שינויים על חי במסד פעיל

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

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

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

עכשיו הבנתי יותר את דבריך, ונראה לי שבעצם כיוונתי לאותו הדבר כשכתבתי

ולמקם אותה במחלקה אחרת שאחראית על הלוגיקה העסקית

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

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

public class Job {
   public string JobName {get; set;}
   public double WorkHours {get; set;}
   ...
   public decimal CalculatePrice()
   {
      ...
      return price;
   }
}

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

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

public record JobSpecifications {
   public string JobName {get; set;}
   public double WorkHours {get; set;}
   ...
}

public decimal CalculatePrice(JobSpecifications specs)
{
   ...
   return price;
}

זה יעיל מכל הבחינות, והרבה יותר קל לתחזוקה.

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

באיזה db אתם משתמשים?

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

SELECT DISTINCT BookName FROM Books

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

אני משער שזה כי השאילתא מכילה שדה אחד או יוצר שמוגדרים לקריאה בלבד. למשל את המפתח הזר (בטבלת הרבים).
הדרך הכי פשוטה לאפשר עריכה היא ליצור טופס מקושר, כלומר טופס בתוך טופס, שטופס האב מכיל את טבלת היחיד וטופס הבן את טבלת הרבים, ולקשר בין הטפסים על ידי שדה המפתח.
ראה דוגמא כאן: https://tchumim.com/topic/10491/אקסס-למתחילים-יצירת-מערכת-לניהול-תורמים/23

@dovid כתב בפקודת מאקרו בוורד שפותחת תוכנה אחרת ויכולה לעשות פעולות בתוך התוכנה האחרת:

@OdedDvir נדמה לי שזה בגלל שהCurrent Directory שלו לא מצביע על התיקיה של פרוייקט השות.

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

Sub CopyAndPasteInResponsa()
    Selection.Copy
    Dim AppPid As Long
    AppPid = GetFirstPid("Responsa")
    If (AppPid = 0) Then
        ChDir "C:\Program Files (x86)\ResponsaCD25"
        AppPid = Shell("RESPONSA.exe", 1)
    End If
    AppActivate AppPid
    SendKeys "^Q", True
    SendKeys "^C", True
End Sub

הוספתי גם את הלחיצה על Q^ לפני ההדבקה.

@האדם-החושב

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

   כלומר הוא מריץ את זה לפני שהתוכנה נפתחת?

4. לא הבנתי את השאלה.

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

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

@laswater כתב בבאקסס- פיתרון ליצירת טופס עם כניסה למנהלים בלבד-ללא שום קודים!!!:

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

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

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

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

Private Function GetFirstPid(applicationName As String) As Long
'Returns the FIRST PID of an application by it's name
    Dim services As Object, processes As Object, process As Object
    Dim resultPid As Long

    Set services = GetObject("winmgmts:\\.\root\CIMV2")
    Set processes = services.ExecQuery("SELECT ProcessID FROM Win32_Process WHERE name like ""%" & applicationName & "%""", , 48)

    For Each process In processes
       resultPid = process.ProcessID
       Exit For ' Just the first ID please :)
    Next
    ' Garbage cleanup
    Set processes = Nothing
    Set services = Nothing
    
    GetFirstPid = resultPid
End Function

Sub CopyAndPasteInResponsa()
    Selection.Copy
    Dim AppPid As Long
    AppPid = GetFirstPid("Responsa")
    If (AppPid = 0) Then
        AppPid = Shell("C:\Program Files (x86)\ResponsaCD25\RESPONSA.exe", 1)
    End If
    AppActivate AppPid
    SendKeys ("^C")
End Sub

אם הבלילה הייתה דלילה מאוד או החומר לא איכותי - יתכן.

צריך ממש מעט מים כדי להגיע מההתחלה לסמיכות הרצויה. משהו כמו יחס של 1 ל-10.
מסתמא עד עכשיו כבר קיבלת את התשובה:
א. זה יתיבש.
ב. זה לא יהיה חזק כמו עיסה.

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

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

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