Forum Replies Created
- Replies
-
- ינואר 23, 2017 בשעה 1:38 am
- in reply to: חקר איטיות במערכת
"תהליכים בביצוע" לא יתן תשובה מלאה – בכלל לא. אם אני לא מבלבל עם דברים אחרים, רשימה זאת כוללת רק תוכנות מסוימות שבית התוכנה בחרה לרשום ברשימה.בכל מקרה לא פשוט לקבל תמונה מלאה של מה שיכול לגרום לאיטיות.
נתחיל מהפחות יתכן אבל לא בלתי יתכן – יכול להיות בעיות ברשת (גם אם מדובר ביום ושעה מסוימת – אי אפשר לשלול הפרעות סביבתיות שישפיעו על ציוד רשת).
ועוד יכול להיות שהדטהבייס של הפריוריטי שלכם יושב על אותה מכונה עם דטהבייסים אחרים ויש שם שאילתאות כבדות שמעמיסות על השרת וגורמות לו לא לענות לשאילתאות שלכם מהר. או אולי יש תוכנות אחרות בשרת הדטהבייס שחונקות אותו.
וגם אם מדובר בפריוריטי יכול להיות שמישהו מריץ משהו כבד מול פריוריטי מתחנה וזה מריץ הרבה שאילתאות.
יש כלים כמו הפרופיילר של SQL Server שיכולים לעזור לאתר פעילות כבדה של פריוריטי אבל איך להפעיל אותם ואיך להבין את תוצאות זה לא דבר שאפשר להסביר כאן על רגל אחת.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 23, 2017 בשעה 1:31 am
- in reply to: שינוי מפתח מוצר
MY Guide כתב:שדה מפתח זהו שדה שמזהה באופן ייחודי את הרשומה.
אני רוצה לדייק במה שיאיר כתב.
מפתח זהו שדה או שדות שמזהה (או מזהים בשילוב) באופן ייחודי את הרשומה.
יכול להיות ששני השדות כוללות ערכים שכל אחד מהם לא יחודי בעמודה אבל השילוב הוא יחודי ולא יכול לחזור על עצמו. שינוי של אחד מהם גם ייחשב שינוי מפתח בגלל שההרכב של שניהם ביחד משתנה.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 22, 2017 בשעה 11:37 pm
- in reply to: משתמשי מערכת
למקרה בו יעזור, נציין את השמות המקובלות:
קוראים להם רשיונות concurrent (בו-זמניות) ורשיונות named (שמיות)[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 21, 2017 בשעה 11:51 pm
- in reply to: העתקה מאקסל
קודם כל למען הסר ספק – אם הוספתם בפיתוח פרטי טבלאות משלכם לצורך תוספות פרטיות – מותר להכניס ישר אליהם – ועל אחריותכם לדאוג שהנתונים תואמים ללוגיקה שלכם.באותה מידה, צריכים להבין שבפריוריטי זה "טריגרים" במסכים ולוגיקה בתהליכי טעינה שדואגים שמה שמגיע לטבלאות זה תקין ומתאים לנתונים במערכת. לדוגמה דרך המסכים אין דרך להכניס מזהה מוצר לטבלה אם לא קיים מוצר בעל מזהה זה. בפריוריטי אין הגנה ברמת הדטהבייס לכלל כזה ולכן אפשר לטעות בקלות ולעשות בלאגן בנתונים.
היות ואין דרך שתוכלי להיות בטוח שאת מכניסה נתונים באופן שתואם לכלל הלוגיקה במערכת, אסור לעשות זאת.
חשוב גם שאציין שבגלל זה אסור לנו כמפתחים לבנות מסכים וכו' שמעדכנים טבלאות סטנדרטיות כי זה יוצא אותו הדבר.
לא מן הנמנע שבבית התוכנה יטעו ויהיו סתירות בקוד שלהם ולא הכל יצמד לאותם כללים אבל אנחנו רוצים לדעת שכשיקרה משהו מוזר ויגלו בעיות בנתונים שנוכל לומר שפעלנו רק דרך הערוצים הנכונים (מסכים באופן ידני, ממשקים למסכים, תהליכי טעינה דרך משטחים וכו') ולא נגענו ישירות בטבלאות.
אני מתנצל על התשובה הארוכה אבל מקווה שכך הכל ברור.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 20, 2017 בשעה 12:20 pm
- in reply to: העתקה מאקסל
לעולם לא מכניסים ישר לטבלאות.אבל יש את האפשרות להשתמש בממשק למסך שזה כמו להקליד את הנתונים. יש בזה אולי טרחה גדולה יותר כי צריכים להתאים את הנתונים למסך יותר ממה שצריכים לעשות במקרה של משטח טעינה, אבל בהסבת נתונים בין מערכות נראה לי שיש בד"כ פנאי ומשאבים להשקיע בזה.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 19, 2017 בשעה 5:57 pm
- in reply to: צורך להגדיר יותר מ- 3 תנאים במחולל נתונים
- ינואר 19, 2017 בשעה 5:55 pm
- in reply to: הגבלת אורך תווים בהקמת מק"ט חדש
אוקיי, הנה תשובה לאחר בדיקה.קודם כל אני חייב להתנצל כי היתה טעות עקרוית בתשובה המקורים שלי – אני כתבתי "שווה" אבל במקרה שלנו, אנחנו רוצים "להציג שגיאה כאשר" ולכן מדובר ב"מק"ט שונה מ-" ולא "שווה ל-".
הביטוי הנדרש, כפי שהגדרתי אותו שלשום, הוא:
STRCAT(<>,(STRLEN(<>)<=16?'':'X'))
וכאן שמתי עם שם שדה באנגלית כדי לא להסתבך כאן התצוגה.
אבל
בעצם זה מיותר. אפשר לעשות בדיקה פשוטה יותר:
כאשר מק"ט לא שווה ל- (שונה מ-)
STRIND(<>,1,16)
דהיינו – אני חותך את המק"ט בתו ה-16. אם המקור פחות מ- או שווה ל-16 תווים אז המקור שווה לתוצאה. אם זה ארוך יותר אז לא שווה ועונים לתנאי (של שוני) ורואים הודעת שגיאה.
הערה:
הגישה הנ"ל יכול לשמש עדיין פתרון למצבים כמו זה שמוזכר בשאלה אחרת בהם רוצים ליישם יותר תנאים ממה שהמערכת נותנת.
צריכים לתפור ביטוי שידאג לכך שרק שעומדים בתנאי השני, מקבלים ערך שיעזור לענות על התנאי הראשון – נגיד את זה באופן אחר: התנאי השני צריך לשבש את הערך שבודקים בתנאי הראשון כך שרק כשעומדים בשני התנאים, נעבור את התנאי החיצוני. לפעמים זה לא פשוט וצריכים לתת לזה לא מעט מחשבה אבל שיטה זאת יכולה מאוד לעזור.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 19, 2017 בשעה 3:18 pm
- in reply to: צורך להגדיר יותר מ- 3 תנאים במחולל נתונים
אתה שאלת על אורך מק"ט
לצערי עדיין לא הצלחתי להקדיש זמן מול המחשב לזה[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 18, 2017 בשעה 6:58 pm
- in reply to: חסימת מעבר שפה
esti כתב:לא נראה לי שאפשר לחסום מעבר שפה
אבל אפשר להגביל מודולים לפי שפה
אבל זה מתאים רק אם אתה מחפש פתרון גורף לכול המשתמשים.
פשוט הסתיר את כל המודולים בשפה שאתה רוצה – המשתמש לא יוכל לעשות כלום ויחזור לשפה הרצויהמנהל המערכת > מילונים > תרגום > הסתרת מודולים ממילונים
רעיון יפה.
חשבתי להשתמש בו עד שהבנתי על מה שמדובר. הרי כפי שכתבת זה לא יבטל את השפה כאופציה.
אצלנו העיצובים שלנו הם באנגלית בריטית. לא טרחנו לתחזק בתוך הסביבה של אנגלית אמריקאית (למרות הבריטית יורשת מאמריקאית).
לפעמים משתמש מחליף שפה ובוחר אמריקאית ואנחנו מקבלים תמונה ש"משהו לא טוב כאן". אם נסתיר את כל הישוית נקבל "אין כלום בתפריט". לא נראה לי שזה יקדם אותנו בהרבה…בואו נקווה שמישהו יצליח יום אחד לשכנע ל
אשבלפריוריטי סופטוור (אני עדיין אומר אשבל, מה אכפת לי) להוסיף אופציה של חסימת שפה.[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 18, 2017 בשעה 4:47 pm
- in reply to: צורך להגדיר יותר מ- 3 תנאים במחולל נתונים
צריכים להיות יצירתיים בסגנון שהזכרתי – במקרה כזה לשלב שתי בדיקות
אני חייב לכם דוגמה מסודרת בדיון הקודם[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 18, 2017 בשעה 11:43 am
- in reply to: SET TRANSACTION
אולי אולי אולי יישום ה set transaction של פריוריטי ברמת התרגום ל-sql של הדטהבייס כולל rollback של כל טרנסקציה שפתוחה?בדרך לבדוק זה בעזרת profiler או כלי דומה ברמת הדטהבייס. יכול להיות שהרצת הקוד שלך במצב דיבוג יגלה משהו אבל אני לא משוכנע בכלל.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 18, 2017 בשעה 11:37 am
- in reply to: הוםעת תגי HTML בדו"ח
עד כמה שאני זוכר החזרת הרוחב המקורי אמור לסדר את זה. באמת החזרת ל-68?[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 18, 2017 בשעה 11:26 am
- in reply to: הגבלת אורך תווים בהקמת מק"ט חדש
אוקיי אולי אעשה זאת בהמשך לאחר בדיקת הסינטקס גם[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 17, 2017 בשעה 3:05 pm
- in reply to: הגבלת אורך תווים בהקמת מק"ט חדש
מיותר לציין אך אציין בכל זאת שלא משנה איזה שדה משווים כי משווים מול אותו הדבר או לא.[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]- ינואר 17, 2017 בשעה 2:53 pm
- in reply to: העתקה מאקסל
בהדבקה צריכים גם לקחת בחשבון דילוג על כל העמודות שהן קריאה בלבד, כך שיצא שמדביקים פחות עמודות ממה שרואים.[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]