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

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

1. קבצי ה-resource לא ניתנים לעריכה בעורך טקסט, בניגוד ל-json. אבל לענ"ד זה חיסרון שבא לידי ביטוי רק בכמות גדולה של מחרוזות, כשרוצים לסקור כמה שפות במקביל, ובמקרה הנ"ל, אף @pcinfogmach ציין שהפתרון שלו לוקה בחסר.
2. לא בדיוק חסרון במנגנון, אבל סתם מעצבן, שבגרסת ה-preview של VS הם ניסו ליצור כלי יותר נוח לתחזוקה של כל השפות במקביל, רק שלא ידעתי שאין תאימות אחורה לגרסה היציבה של VS, וה-resources לא ייפתחו שם אח"כ...

למרות האמור לעיל, אחרי עקומת הלמידה של ה-setup הראשוני, היישום בקוד ממש נוח לדעתי, ואני משתמש בזה תדיר.

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

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

להלן הצעדים הנדרשים:

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

pnputil /enum-drivers

כדי לאתר את הדרייבר שלך, לחץ על Ctrl+Shit+F ותקליד בחיפוש:

gemalto

אחרי שמצאת את הדרייבר, שים לב מה הערך ב-Published Name:. הוא מתחיל באותיות oem ואחריהן מספר כלשהו, למשל:

Published Name:     oem12.inf
Original Name:      whatever...
Provider Name:      Gemalto

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

pnputil /delete-driver oem12.inf /uninstall

2. כעת תוכל להקין את הדרייבר החדש מכאן:
   https://supportportal.gemalto.com/csm?id=kb_article_view&sys_kb_id=68db1c5edb9bbe40d298728dae9619e9&sysparm_article=KB0015847
   ולהשתמש בו בלי לבטל את ההגנה הנ"ל.

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

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

ב-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 או שאינם נוגעים בעדכון נתונים, כמו מה הדף הכי נצפה, התנהגות המשתמש עם האפליקציה, הזמן שלקח לבצע חישוב מסויים, וכו'.