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

@mekev
זה עובד?

cell.OwningColumn.HeaderText

@mekev
עדכון:

מצאתי 'היסק סביר'
פשוט לבדוק את ה: this.Width / this.Height

@mekev
בבקשה קישור לאתר
https://yehoshua-rba.co.il/?utm_source=hameanyenim&utm_medium=email&utm_campaign=guide

מגיגול קצר, בלי נסיון,

בחשבונות אישיים זה לא אפשרי, אבל אם מדובר בחשבון עיסקי (google workspace) ניתן לראות את ההיסטוריה כאן
https://meet.google.com/tools/quality/admin
וראה כאן בהרחבה:
https://support.google.com/a/answer/9186729?hl=en

להבא ניתן לתעד את ההיסטוריה גם בחשבון אישי באמצעות תוסף זה למשל
https://chrome.google.com/webstore/detail/tactiq-transcribe-google/fggkaccpbmombhnjkjokndojfgagejfb

@קומפיונט כתב בזיהוי לחיצת קליק ימני / קליק שמאלי בעכבר:

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

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

@חגי כתב בWPF + Entity framework -information:

MAUI

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

@mekev לא ברור מהתמונה לפי מה אתה ממיין את השורות.

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

http://sqlfiddle.com/#!18/0c0d6/3

WITH cte (date, price, data, rank) AS ( SELECT *, RANK() OVER (ORDER BY date) AS rank FROM table1 ) SELECT cte.date, cte.price, cte.data FROM cte LEFT JOIN cte AS cte1 ON cte1.rank = cte.rank - 1 WHERE cte.rank = 1 OR cte1.price <> cte.price;

הסבר קצר:
יש שימוש ב-WITH ללכוד את הטבלה עם עמודה נוספת בשם rank שמייצגת את המיקום של העמודה בסדר המיון (פוקנציית RANK היא "פונקציית חלון")
ואז אנחנו מחברים את הטבלה עם עצמה כדי לקבל את השורה הקודמת עם השורה הנוכחית
ואז מסננים לפי rank = 1 שזה השורה הראשונה או שהמחיר של שורה זו לא זהה למחיר של שורה הקודמת

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

אולי ניתן לעשות סוג של דירוג נוסף

בעצם, יש הבדל בין 'מועיל' לבין 'נהנתי' ולבין 'נכון'.

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

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

אז אני מצטרף לבקשה (כמובן אם מעשי וכו', לא יודע כמה קוד ועריכה זה דורש) לבדל ל2 דירוגים - 'מועיל', ו'נכון'.

(אפשרויות נוספות לשמות הדירוגים: 'הועיל לי', 'אני מסכים' וכדו'.

או בכלל להביע את זה באייקון של V ו X ל'נכון', ואייקון אחר - אין לי רעיון עכשיו, ל'מועיל')

@mekev כתב בשרשור הודעות בג'יימייל:

איך וכיצד לשלוף את המזהה והנושא להצגה למשתמש
שיוכל לבחור לאיזה מייל להגיב

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

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

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

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

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

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

3. פיצול קבוצות של מידע אופציונלי מהטבלה

בעצם זה אותו מקרה של 2, רק שיש פה שני ייתרונות נוספים אפשריים

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

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

@mekev ככה

if ((bool)dataGridView1.CurrentCell.EditedFormattedValue) { current_payment = Math.Min(tb1Val, debt_balance) dataGridView1.CurrentRow.Cells["current_payment"].Value = current_payment; textBox1.Text = Math.Max(tb1Val - current_payment, 0).ToString(); }

@yossiz
מדובר על SSMS (צודק לגבי הצורך בדיוק, החכמתי)

מה אני מנסה לעשות?
אני מעוניין להריץ שאילתא שתחזיר תוצאות משלוש DataBase
ולצורך כך אני משתמש בOUTER APPLY

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

@liy770 אמר בתקלה בחיפוש:

זה באג ידוע, אין צורך לכתוב על כך שוב

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

בהקלדת תווים בעברית - יקפוץ חלון 'פופאפ'
ו/או
במקום/בנוסף ל'לא נמצאו תוצאות'
להוסיף פאנל מידע על הנ"ל

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

7c1faf60-1880-43ad-8c42-3bc9b38b3bb7-image.png

@mekev אמר בהצעה לשיפור התועלת מהתשובות:

אולי שווה לצרף
גם מה חפשת בגוגל שהביא לך את התשובה

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

@mekev אמר באיך ניתן להוסיף פס גלילה (Scrollbar) לתא בעמודה ספציפית בטבלה (c# - winforn):

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

את זה תוכל לפתור על ידי הוספת סימון כלשהו שיסב את תשומת הלב של המשתמש
תוכל להוסיף את הסימון לתוכן של התא באירוע CellFormatting או בצורה יותר מסובכת, להתאים אישית את ה-paint של התא, כמו שמתועד פה

@yossiz אמר בכלי לצילום מסך:

יש גם גירסת בטא עם תיקונים ועדכונים
https://github.com/greenshot/greenshot/releases/tag/v1.3.265

(הגירסה היציבה האחרונה שוחררה לפני חמש שנים, והרבה מים זרמו בירדן מאז)

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

@mekev אמר בפילטור שינויים בלבד לתצוגת המשתמש:

או שבכלל צריך לשמור מראש את השינויים בצורה שונה שתאפשר את השליפה הנ"ל)

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

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

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

ובמקרים אלו ניתן להפעיל את התוסף הזה
https://chrome.google.com/webstore/detail/google-translate/aapbdbdomjkkjkaonfhkkikfgjllcleb

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

לדוגמא, בiframe שמוטמע בדף זה לא עובד,

מעניין שמנגנון התרגום של edge מבוסס כרומיום עובד לדעתי בצורה טובה יותר, וגם משנה מltr לrtl בתרגום מאנגלית לערית.

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

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