אני לא יודע (אני אישית גם מחוץ לקבוצה). זה קבוצה של מתנדבים שהתגבשה בפרוג ובערוצים אישיים, המנהל הוא GolanArt. אולי הוא יגיב פה איך מצטרפים.
פורסם במקור בפורום CODE613 ב02/11/2014 09:58 (+02:00)
אני לא יודע (אני אישית גם מחוץ לקבוצה). זה קבוצה של מתנדבים שהתגבשה בפרוג ובערוצים אישיים, המנהל הוא GolanArt. אולי הוא יגיב פה איך מצטרפים.
פורסם במקור בפורום CODE613 ב02/11/2014 09:58 (+02:00)
אולי זה יעניין אתכם, מפת הדרכים של צוות ADO.NET לגבי הEF (הגירסה הבאה - 7).
הנה שתי פוסטים חשובים:
http://blogs.msdn.com/b/adonet/archive/2014/05/19/ef7-new-platforms-new-data-stores.aspx
http://blogs.msdn.com/b/adonet/archive/2014/10/21/ef7-what-does-code-first-only-really-mean.aspx
מדובר על תמיכה מובנית בSQLite(!) ועוד. וגם עזיבת קובץ הEDMX קובץ XML ששימש להגדרה הצהרתית של מבני הנתונים שיכל להיווצר אוטומטית מהDB. במקום זה נשאר רק הCodeFirst (אבל גם אותו ניתן ליצור מהDB אוטומטית וגם ניתן עם כל מיני כלים ליצור אותו ממודל ויזואלי).
פורסם במקור בפורום CODE613 ב28/10/2014 12:25 (+02:00)
מה הDB אשם שאתה מנסה להוציא ממנו מצגת 
פורסם במקור בפורום CODE613 ב27/10/2014 12:49 (+02:00)
ארכיטקט אתה תמצתת בצורה יוצאת דופן בשאלה, לתשומת לבך.
בקשר לשאלה, אני חושב שא"א להטמיע את התוכנה הזו בשלך, אלא עליך למצוא פקד מציג TIFF נוח וחינמי.
פורסם במקור בפורום CODE613 ב28/10/2014 10:59 (+02:00)
הרבה יותר הגיוני לשאול להפך, מה הגיון לבזבז מחלקה שלמה בIPv4 לצורך זה.
ראה בקטע הזה מה שהוא כותב בסוגריים... (לקוח מפה).
Like IPv4, provision has been made for a special loopback address for testing; datagrams sent to this address “loop back” to the sending device. However, in IPv6 there is just one address for this function, not a whole block (which was never needed in the first place, really!) The loopback address is 0:0:0:0:0:0:0:1, which is normally expressed using zero compression as “::1”.
ראה גם http://serverfault.com/questions/193377/ipv6-loopback-addresses-equivalent-to-127-x-x-x
פורסם במקור בפורום CODE613 ב26/10/2014 10:30 (+02:00)
ארכיטקט, "בשביל לא להכביד על מערכת אחת דרושה מערכת אחרת" כך נשמעת השאלה.
מילא אם המערכת הא' הייתה מיועדת לפעולה אחרת בעיקר, אז מונעים ממנה עומס של פעולה שהיא לא ממוטבת לעשותה, אבל זו אותה פעולה בדיוק.
הרציונל האמיתי של השאלה כנראה הוא למנוע עומס על המכונה (= מחשב) בה נמצאת מערכת א' משום שהיא איטית/יקרה/ברשת לעומת המכונה של מערכת ב' שמהירה/זולה/מקומית. כך שבעצם לא משנה בכלל המערכות אלא אפשר לעובד בשתיהם בMySql (להתקין גם במכונה בה המחשב "זוחל". אפשר להשתמש במגוון מסדי נתונים אחרים כמובן ואף במה שהציע magicode).
לגבי הרעיון של XML. סכמת XSD שהיא הנורמה כיום להגדרת נתונים בXML, תומכת בערך בלעדי, ובעוד אילוצים ואף קשרי גומלין. המשמעות של התמיכה הזו מסתכמת בכך שמי שיפר את האילוץ אז המסמך ייחשב ללא תקף. כי XML זה לא מערכת/מנוע/דרך פעולה, זה סה"כ מוסכמה איך לכתוב נתונים. אז זה לא ממש אמור לשנות לך. אתה יכול להחליט היום על מוסכמה כל שהיא, זה יפתור את הבעיה? המימוש של האילוץ של ערך יחידני תמיד נעשה ע"י המחשב, במקרה MySQL אז התוכנה שלהם דואגת לזה, ובXML אז התוכנה שלך היא זו שתעבוד קשה. שים לב שאין מצב שתעשה זאת ביעילות בה עושה זאת הMySql ואף לא תגיע לקרסולי קרסוליה של יעילות זו.
פורסם במקור בפורום CODE613 ב20/10/2014 13:40 (+03:00)
זה ENUM בשם DialogResult
שים שם DialogResult.OK
לא. אתה מחליף עם winforms. בwpf זה מאפיין בוליאני (ראה לינק להלן).
תודה על התגובות עד כה.
לצערי הנסיון להגדיר את החלון עם דיאלוג ריזאלט=טרו.
זורק חריג.
דקדקתי לכתוב:
@דוד ל.ט.
שים לב ש**[u:6ax7yavg]בקוד החלון הנקרא[/u:6ax7yavg]** עליך לתת תשובה: DialogResult = true;
בתוך הקוד של החלון Wellcom אתה צריך להגיב בשלב כל שהוא ולענות לחלון המקור שקרא לחלון הזה (נגיד המשתמש כותב את שמו ולוחץ על הפתור "אישור"). בשלב בו החלון Wellcom "גמר" עם המשתמש וקיבל ממנו תשובה או אי תשובה, הוא מחזיר לחלון המקור במאפיין הזה האם אכן ישנה תשובה רלוונטית.
ברגע שאתה כותב בקוד DialogResult = true; זה סוגר את החלון והקוד הקורא מתעורר מ"קפאונו" וממשיך לרוץ. הוא יכול לבחון את התשובות מהחלון Wellcom ע"י פנייה למאפייניו.
הנה תיעוד של המאפיין עם הסבר אף לשתי מקרי השגיאה האפשריים.
אגב בWPF השגיאה תמיד נמצאת בinner exception, לא משנה מה זה ולמה זה ככה, בכל אופן בגירסת הVisual Studio שברשותך א"א לצפות בשגיאת המקור. ממילא אני מאוד ממליץ לך לעבור לVisual Studio Ultimate שהיא "עקרונית" בתשלום, שמה אתה יכול לראות את לשון השגיאה המקורית שבמקרה זה היא: DialogResult is set before a window is opened by calling ShowDialog.
עריכה:
אני טעיתי. לשון ההודעת שגיאה היא: DialogResult can be set only after Window is created and shown as dialog., וזה כאילו המאפיין הוגדר לפני/ללא קריאת הShowDialog. וזה לא נכון, אלא הבעיה היא שהמאפיין נקרא אחרי הClose של הטופס. לשון הודעת השגיאה בטעות לא מכסה את המקרה הזה.
פורסם במקור בפורום CODE613 ב21/10/2014 14:52 (+03:00)
ברכות לשלב בו אתה נמצא!
בUI, עצירת תוכנית בד"כ מתבצעת ע"י חלון קלט מודאלי - חלון חדש שא"א לעוזבו בלי ביטול/אישור והתוכנה ממתינה לתשובתו בשביל להמשיך בקוד. פעולה זו מושגת ע"י הרצת מתודת ShowDialog לחלון WPF. שים לב שבקוד החלון הנקרא עליך לתת תשובה: DialogResult = true;
התשובה שלי אופיינית לבעיה הספציפית. בהצלחה!
פורסם במקור בפורום CODE613 ב06/10/2014 13:03 (+03:00)
בדוק את זה גם:
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)
@דוד ל.ט.
נו ומה קורה אם תשים 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)
sencha עולה 1000$
קראת טוב מה שכתוב שם?
עד כמה שהבנתי זה לגמרי בחינם.
התשלום זה על תמיכה.
איך עובדים עם זה אין לי מושג, אני מכיר את זה לראשונה מאז קריאת האשכול הנוכחי 
פורסם במקור בפורום CODE613 ב17/09/2014 10:46 (+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)
אני פיתחתי כמה וכמה שיטות שונות ועדיין "ס'איז נישט"
אשמח להפניה ל 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)