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

בדוק את זה גם:
https://www.mediawiki.org/wiki/API:Query
http://he.wikipedia.org/w/api.php

בהצלחה.

פורסם במקור בפורום CODE613 ב30/09/2014 11:45 (+03:00)

בקטע של אבטחת מידע האתרים של הממשלה הם בסדר לגמרי, תבדקו אותם. בעצם אתם לא צריכים לבדוק, עושים זאת ממילא אלפים כל הזמן.
אבל ניסיתי לבטל את הJS+MaxLength ולשלוח OR בשדה המספר שמה זה לא עובד אך אין דחיה מהשרת. אם עובדים קשה אולי אפשר למצוא חורים קטנים, האתר בנוי בWebForms כנראה ASP.NET 4.
בקשר לשאלה שאין כאן בכלל הזרקה, אז ההתנהגות היא לפי הבדיקות שלי שכל פעם שיש בקלט OR או AND (עם רווחים לפני ואחרי) אז החיבור מתנתק ומסרב לענות לפרק זמן.

פורסם במקור בפורום CODE613 ב01/10/2014 11:50 (+03:00)

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

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

פורסם במקור בפורום CODE613 ב29/09/2014 12:21 (+03:00)

@softs

@דוד ל.ט.

נו ומה קורה אם תשים Try על כל הקוד של התוכנית? אז זה קופץ מחוץ לבלוק הTry = מחוץ לתוכנית.

יש ויש, במקרה שלו בגלל המבנה של ה UI של WPF האירוע של ה Dispatcher תמיד מועבר ל UI THREAD הראשי ולכן כשקורה EXCEPTION כזה אפשר לעשות CONTINUE (בניגוד ל Thread.UnhandledException) וזה לא מעיף את התכנית אלא את ה Message ב Thread הרלוונטי

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

פורסם במקור בפורום CODE613 ב16/09/2014 13:24 (+03:00)

ברור שהיא תקרוס. אלא מה?
מה קורה בTry? יש קטע קוד שאם יש בו שגיאה, קופצים לבלוק הקאטצ ואח"כ הלאה.

נו ומה קורה אם תשים Try על כל הקוד של התוכנית? אז זה קופץ מחוץ לבלוק הTry = מחוץ לתוכנית.

אם אתה רוצה מצב בו כל שורת קוד בתוכנה מוקפת בTry [u:3n3ivzq6]משלה[/u:3n3ivzq6], שים לב שאילו זה היה רצוי אז לא היו צריכים try בכלל, פשוט כשהמחשב היה נתקע בשורה מסוימת הוא היה קופץ עליה. הסיבה שזה לא ככה זה בגלל שזה יכול לעשות תוצאות ממש ממש לא רצויות. אם יש לך קוד ש"גוזר קובץ" אתה יכול למחוק אותו אפי' שהעתקה לא התבצעה וכדומה.

פורסם במקור בפורום CODE613 ב16/09/2014 11:07 (+03:00)

@HUBHCBH

sencha עולה 1000$

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

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

פורסם במקור בפורום CODE613 ב17/09/2014 10:46 (+03:00)

@HUBHCBH

שווה את המחיר?

? מה עולה וכמה?

פורסם במקור בפורום CODE613 ב16/09/2014 13:10 (+03:00)

@שמואל

זה לא תמיד יהיה נכון לעשות מופע חדש

עניין של גישה, אכן אני בעד זו שלך.
שים לב שבווב זו לא אופציה...

@שמואל

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

זה כבר לא טענה, כי זה רק עניין של קצת קוד נוסף: צריך לקבוע ידנית את הState לModifeid ולהוסיף לDbContext החדש ולשמור וזהו.

פורסם במקור בפורום CODE613 ב11/09/2014 11:22 (+03:00)

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

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

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

DbContext.Table.Remove(Item);

במקרה של עריכה, אפשר פשוט לקבוע את הערך של EntityState כUnchanged, וממילא הDbContext לא ישלח עדכון על אייטם זה. בשביל לשחזר את הערכים המקוריים לאייטם שבזיכרון הDbContext אפשר ככה:

var entry = DbC.Entry(Item);
entry.CurrentValues.SetValues(entry.OriginalValues);
entry.State = EntityState.Unchanged;

או (מיותר קצת) לתשאל את הDB שוב לגבי פריט זה ע"י פקודת Refresh של הDbContext.

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

פורסם במקור בפורום CODE613 ב11/09/2014 11:05 (+03:00)

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

פורסם במקור בפורום CODE613 ב26/08/2014 12:54 (+03:00)

@ארכיטקט

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

גם מיקרוסופט כותבים כך.
גם ויקיפדיה מתייחסים לשימוש זה בפרט בהקשר של sql server, אגב הערך חדש לי ושווה בדיקה http://en.wikipedia.org/wiki/Log_trigger

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

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

...The trigger is mostly used for maintaining the integrity of the information on the database. For example, when a new record (representing a new worker) is added to the employees table, new records should also be created in the tables of the taxes, vacations and salaries.

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

אגב השיטוט, פתרונות מהרשת נוספים באותו עיקרון שלכם - ארכיטקט וsoft - מבוססים על טריגר
http://weblogs.asp.net/jongalloway/adding-simple-trigger-based-auditing-to-your-sql-server-database
http://www.softcodearticle.com/2012/11/imlementing-generic-audit-trail-trigger-in-sql-server/

פורסם במקור בפורום CODE613 ב26/08/2014 16:56 (+03:00)

@softs

אני פיתחתי כמה וכמה שיטות שונות ועדיין "ס'איז נישט"
אשמח להפניה ל THREAD הספציפי

ארכיטקט כתב כמה אשכולות והוא השקיע בנושא. ראה http://code.613m.org/viewtopic.php?f=1&t=211
אבל לא כתבתי שם את טענתי האחרונה שהתגבשה אחרי כן.
תוכל לראות הרבה מאמרים באינטרנט על דרכים למעקב שינויים, ושימוש בכלים המובנים של MSSQL לכך.
הנה למשל: http://www.codeproject.com/Articles/537649/SQL-Server-Change-Tracking-CT

פורסם במקור בפורום CODE613 ב25/08/2014 19:48 (+03:00)

@softs

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

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

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

זה מה שהתכוונתי, ייתכן שאני טועה.

פורסם במקור בפורום CODE613 ב25/08/2014 18:27 (+03:00)

@MacroShadow

בטבלה יש לשמור כל פעולה שנעשתה בפנ"ע.
סיכומים ושאר ירקות [u:1x8fdcqg]רק[/u:1x8fdcqg] בשאילתות.

@מלא

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

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

פורסם במקור בפורום CODE613 ב25/08/2014 16:39 (+03:00)

בטמפלט/סטייל עצמם צריך להשתמש עם RouteEvent/EventSetter בהתאמה כדי לנתב לקוד (אותו כותבים בapp.cs), רק שזה עובד רק עם RotedEvent שזה האוננטים המיוחדים של WPF ולא עם אוונטים רגילים - אותם א"א לנתב לקוד מתוך סטייל/טמפלט. במקרה של חלון אין אירועי WPF לסגירה רק אירוע פרימיטיבי.
לכן אתה צריך לעשות אחרת: לבנות מחלקה בקוד שיורשת מWindow ולשנות בכל החלונות את המילה Window לשם המחלקה שלך (למשל myNs:MyClassWin) וגם בקוד לשנות את הירושה במקום מWindow למחלקה שלך.

בapp.cs תוכל לעצב בסטייל/טמפלט ישירות את המחלקה שלך.

פורסם במקור בפורום CODE613 ב13/08/2014 20:49 (+03:00)

זה נראה לי כן קשור להרשאות, אבל לא בהכרח שאדמיניסטרטור מועיל כאן.
זה עניין של בעלות כמבואר כאן: http://superuser.com/a/277597/292722
ואם הבעלים זה system למשל אז האדמיניסטרטור לא יכול לשנות עד שהוא ייקח בעלות. דרך הregedit זה כנראה משתמש ביוזר system.

צריך לבדוק את העניין.

פורסם במקור בפורום CODE613 ב13/08/2014 21:07 (+03:00)

אנו הולכים על כיוון של פשרה - הקלת ההרשמה וההתחברות כמה שניתן.
אנו עובדים כעת על חיבור באמצעות הרשתות החברתיות:
gmail
windows live
linkedin

ועוד.

פשרה טובה?

פורסם במקור בפורום CODE613 ב10/08/2014 21:17 (+03:00)

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

אנו מזמינים בזאת הערות והארות וביקורת בונה

פורסם במקור בפורום CODE613 ב03/08/2014 18:49 (+03:00)

http://code.613m.org/viewtopic.php?t=235&p=1651

פורסם במקור בפורום CODE613 ב29/07/2014 16:15 (+03:00)

@magicode

@ארכיטקט לפעמים נדמה שאתה חושב שSQL רץ בדרך ניסית. בלי לזלול משאבים. לא משנה מה הוא עושה.
סוג של magicode כזה.

גם אם הוא גולם איטי הוא אמור לפחות להיות עקבי.

פורסם במקור בפורום CODE613 ב31/08/2014 13:11 (+03:00)