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

@חגי כתב בממשק ניהול חינמי לשרת לינוקס:

אני לא חושב שזה איסור, אולי זה משהו ב"הרגשים", אבל זה שם של עבודה זרה.

ב-GPT תוכל למצוא עוד הרבה מקרים כאלו (Oracle למשל), אבל זו כבר סטייה מהנושא...

@איך-ווייס-נישט כתב בטופס באקסס המציג נתונים מטבלה בשילום משאילתה:

אני בד"כ מוסיף טופס משנה המבוסס על השאילתה במצב לא גלוי ואז אני מוסיף פקדים לא מאוגדים ובנתונים אני כותב =[טופס משנה]![שדה מבוקש].

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

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

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

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

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

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

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

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

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

באופן עקרוני, אם השאילתא ניתנת לעריכה, אתה יכול לבסס את הטופס עליה וזהו.
הנקודה היא האם היא אכן ניתנת לעריכה.
יש בזה כמה תנאים וחילוקים, כמפורט יפה כאן https://stackoverflow.com/questions/24267398/why-is-my-query-not-updateable
במקרה שלא, למשל בשאילתת קיבוץ, בה אתה רוצה להציג שדה מחושב ובו סיכום של כמה רשומות, פעמים רבות ניתן להתמודד עם המגבלה כך: לבסס את הפקדים הניתנים לעריכה על שאילתה רזה המכילה רק את השדות הרלוונטיים, וממילא היא ניתנת לעריכה, ואת השדות המחושבים לשלוף משאילתא אחרת.

@שלום-עולם-0 כתב באי דיוק של MouseEvent על קנבס:

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

לא הצלחתי לשחזר את הבאג

מה יכולה להיות הסיבה לבעיה?

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

או איך אפשר להתגבר עליה?

תוכל להדפיס לקונסול באופן רציף את את ערכי event.clientX ו event.movementX לפני שאתה משנה את השעה ולבדוק מדוע החישוב שגוי

שמא הגדרת בטעות הצגת קודי שדה?
נסה ללחוץ Alt+F9 כדי להחליף בין המצבים
ההגדרה עצמה נמצאת כאן:

@אלי כתב בהחיים הם לא טבלה באקסס:

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

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

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

את המאזן של כל הלוואה אתה צריך לחשב לפי סוג התנועה
כלומר אתה יכול לדעת שבחודש 9 הוא אמור להחזיר 100 ש"ח ובפועל הוא החזיר 42.5 ש"ח וכו'
ואתה יכול לדעת מה המאזן שלו בכל רגע נתון ע"י חישוב כל התנועות ממועד ההלואה

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

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

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

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

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

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

לגבי ניהול מטופלים, אני לא מכיר תבנית מוכנה

יש את התבנית Access Patient Visit Hospital Medical Doctor Database Templates [Access-Templates.Com].accdb מהאתר access-templates, אבל אין בה יותר מדי, רק 3 טפסים ושאילתא.

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

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

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

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

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

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

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

אני אולי טועה במשהו?

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

@mekev כתב בmssql - התייעצות כיצד לשמור שינויי עריכה בטבלאות:

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

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

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

@mekev כתב בmssql - התייעצות כיצד לשמור שינויי עריכה בטבלאות:

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

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

@mekev משום מה הגיוני לי יותר (לתפוס מנהג השוטים ו)לענות לך על אחרון ראשון:

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

2. ספרייה מומלצת?
אני לא עובד עם node.js אבל נראה ש Pino ו-Winston ספריות פופולאריות מאוד. שתיהן תומכות בלוגים מובניים, אבל Pino דורשת פחות קונפיגורציה.

3. מישהו יודע האם (תיעוד ב-SQL) עובד טוב ויעיל או שזה תוקע / גורם מורכבות בטרנזקציות וכו'?
הייתי נוטה להתרחק מהכיוון של תיעוד ברמת ה-SQL, אא"כ מדובר במערכת קטנה מאוד עם מעט מאוד רעש, או לחילופין במערכת קריטית שיש בה צורך לתעד כל פיפס בזמן אמת. במקרה האחרון מסתמא הייתי רושם את התיעוד ל-db אחר.
אני לא מספיק מומחה לדחות בידיים את הרעיון, אבל על פניו 3 טריגרים על כל טבלה נשמע לי מאוד מרתיע.
הסיבה היא שלרוב צד ה-db הוא צוואר הבקבוק במערכת, ולתיעוד ב-SQL יש מחיר גבוה.
הגע עצמך, אם כל שינוי של שדה בטבלה משכפל את הרשומה לטבלה אחרת, זה אומר שנפח הנתונים שלך עשוי לגדול בצורה מעריכית, לדוגמא, אם ביצעת 2 פעמים (בטרנזקציות נפרדות) עריכה של שדה מספר הטלפון של משתמש - שיכפלת את כל הרשומה שלו 3 פעמים. אם ערכת את השם שלו - שיכפלת פעם נוספת. אפילו אם הקלדת את הרשומה שלו בצורה חלקית, כי לא היה לך בהתחלה את הכתובת שלו, כשתערוך את השדה של הכתובת - תשכפל שוב את כל הרשומה. מחקת ערך בשדה בודד - שכפלת שוב. אני חושב שאתה קולט את התבנית.

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

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

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

תיעוד בשכבת ה-SQL
יש ל-SQLServer יש אפשרות מובנית לתיעוד על ידי שימוש במעקב שינויים
ראה כאן מדריך בנושא: https://www.sqlshack.com/creating-a-sql-server-audit-using-sql-server-change-tracking/
היתרון באפשרות הזו הוא: שהכל מתחיל ונגמר ב-SQL, ללא צורך בכלים נוספים
החיסרון בגישה הזו הוא: שהכל מתחיל ונגמר ב-SQL... קשה מאוד לתשאל את הנתונים במקרה שרוצים לחקור אירוע, התיעוד מבוצע לתוך הDB, ולא לתוך קבצי טקסט חיצוניים, ושיטה זו עלולה בקלות להוסיף המון רעשי רקע לפעילות השוטפת של ה-DB

תיעוד בשכבת DAL
אם יש לך שכבת DataAccess, למשל API שמבצע את השליפה של הנתונים.
בדוטנט מומלץ להשתמש בכלי תיעוד כגון Serilog
שיטה זו היא העדיפה ביותר: אפשר לבנות לוגים מבניים Structured logs שניתנים לתחקור בקלות על ידי כלי אנליטיקה של לוגים, כמו SEQ
אפשר לתעד לקבצי json יומיים, לשלוט על כמות המידע שנצבר ולהגדיר מתי למחוק לוגים ישנים, ל-Serilog יש אפשרות לנקז את הלוגים שלו לכמה אפיקים במקביל. למשל: תוכל לשלוח בו זמנית את הלוגים שלך לקבצים בדיסק, לקונסול, וגם לשרת לוגים כמו SEQ או QRadar שנותנים לך המון אפשרויות להצגה נוחה של הפעילות, ניתוח ושאילתות פילוח (מי המשתמשים שנכנסו הכי הרבה בחודש האחרון, מה הזמן הממוצע שמשתמש מחובר למערכת וכו')
החיסרון? לא תמיד יש שכבת DAL מסודרת. אבל אם זה המקרה, אז יש כאן בעיה הרבה יותר גדולה מבעיית חוסר התיעוד.

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

CREATE PROCEDURE [dbo].[fn_GetJsonData]
-- =================================================
-- Description:	Get JSON data from a table row
-- =================================================
    @TableName NVARCHAR(max),
    @Id INT,
    @Columns NVARCHAR(max) = '*',
    @JsonData NVARCHAR(max) OUTPUT
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @Sql NVARCHAR(max) = 'SELECT @JsonData=(SELECT TOP 1 ' + @Columns + ' FROM ' + @TableName + ' WHERE Id=' + CAST(@Id AS VARCHAR) + ' FOR JSON AUTO, WITHOUT_ARRAY_WRAPPER)'

    EXEC sp_executesql @Sql,
        N'@JsonData NVARCHAR(max) OUTPUT',
        @JsonData OUTPUT
END
GO

טבלת תיעוד פשוטה:

CREATE TABLE MySimpleAudit (
    Id INT identity(1, 1) PRIMARY KEY,
    TableName NVARCHAR(max),
    OriginalData NVARCHAR(max),
    NewData NVARCHAR(max),
    LogTimeStamp DATETIME2 DEFAULT getutcdate()
    )

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

-- Init variables:
DECLARE @OriginalData NVARCHAR(max), @NewData NVARCHAR(max);

-- Get original data:
EXEC [dbo].[fn_GetJsonData] @TableName = 'Payments',
    @Id = 1234,
    @Columns = 'Id,Amount',
    @JsonData = @OriginalData OUTPUT

-- Do manipulations on the table:
-- ...........
---

-- Get Changes:

EXEC [dbo].[fn_GetJsonData] @TableName = 'Payments',
    @Id = 1234,
    @Columns = 'Id,Amount',
    @JsonData = @NewData OUTPUT

INSERT INTO [MySimpleAudit] (TableName, OriginalData, NewData)
VALUES ('Payments', @OriginalData, @NewData)

@בעל-כישרון כתב בשרת לאקסס:

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

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

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

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

איפה ראית שממליצים על זה?

@בעל-כישרון כתב בשרת לאקסס:

שמעתי על שרפויינט של מיקרוסופט, האם יש מישהו שיודע להמליץ, אם זה תואם למטרה הזו?

SharePoint עבור אקסס נזנח מזמן

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

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

לצערי אני לא מכיר את AppSheet כדי לחוות עליו דעה.