@דוד ל.ט.
אפשר לעשות טאב קוטרול, ובמקום חלונות להשתמש בטאב אייטמס.
אם רוצים לארח חלונות ממש, זה סיפור רציני שמצריך מציאת מחלקה מתאימה.
זה פשוט מאוד, במקום חלון עושים יוזר קונטרול, אם אני מבין נכון אתה יכול להשתמש בו כפונקציונליות של חלון לכל דבר, והוא יכול להתארח בכיף בתוך טאב.
פורסם במקור בפורום CODE613 ב07/04/2014 13:36 (+03:00)
זה הפתרון:
select c.pai/2 as field ,* from (select 345*3.141 as pai) as c
למה? לא יודע, כנראה צריך להריץ קודם כל את שאילתת המשנה ולתת לה שם.
פורסם במקור בפורום CODE613 ב02/04/2014 13:51 (+03:00)
כן ישות הוא איש קשר בין אם הוא ספק, לקוח, מתווך, שנורר או חתול בית. לכולם יש כתובת, טלפון, פקס, עם כולם יש דרכי התקשרות כלשהם, כשתתחיל לבנות אחר כך מחלקות, למיילים SMS ועוד, תמצא את עצמך לפני שוקת שבורה. אל תעשה את הטעות בשום אופן לעשות אותם בשני טבלאות. זה נוגד את כל התיאוריה של מסד נתונים יחסי.
פורסם במקור בפורום CODE613 ב11/03/2014 14:41 (+02:00)
הם חשפו את כל המבנה של הדטה בייס שלהם (בנוי בSQL SERVER 2008 אגב) ואתה יכול פשוט להריץ שם שאילתה ולקבל תוצאות. מדהים!!! הלוואי וגם גוגל היתה מאפשרת את זה 
למי שלא ידע
תהנו :lol: :lol: :lol:
פורסם במקור בפורום CODE613 ב05/03/2014 18:38 (+02:00)
שימושי ביותר!
with cte as
(select 1 i union all
select i+1 i from cte where i < 200)
select cte.i as value ,LAG(cte.i) OVER (ORDER BY cte.i) PreviousValue from cte
OPTION (MAXRECURSION 200);
מקור: אתר מוצלח ומקצועי מאוד אגב ב SQL SERVER ויש שם גם אופציה לקבל ערך מרשומה הבאה
על הדרך גם הבאתי את האופציה להגדיל לולאה בשאילתה רקורסיבית (ברירת המחדל היא 100, אפשר לעשות 0 ללולאה בלתי מוגבלת או טווח מספרים עד 32767). מקור
פורסם במקור בפורום CODE613 ב25/02/2014 15:11 (+02:00)
@ClickOne
@magicode
אני לא יודע מה המטרה של השליחה של הpdf אבל תשקלו אולי לשלוח ישר בתוך הhtml של המייל את הנתונים. זה לדעתי יותר קל מלבנות pdf וגם אין בעיה שם עם עברית.זה קבלה, ולא כ"כ פשוט לפי חוקי מס הכנסה ליצור את זה עם HTML, כי אפשר לשנות את הקובץ.
אא"כ ליצור HTML, ואז לסגור את הקובץ לPDF.איפה כתובים החוקים האלו. ומה הטעם.
חוקי מס הכנסה כתובים כאן והטעם שלא יוכלו לזייף מסמכים. למעשה מס הכנסה לא יודעים שכל קובץ אפשר לשנות, כל ערך במסד נתונים ניתן לשינוי, או שהם בונים על זה שמתכנתים מרוויחים מעט מידי ואין להם זמן לזייף מסמכים :lol: :lol: :lol:
פורסם במקור בפורום CODE613 ב26/02/2014 18:17 (+02:00)
אז ככה, נמצא סוף סוף ספק אחד מקצוען באמת, ובמחירים שלא ייאמנו מבחינת שליחת הודעות 3 אגורות להודעה + מע"מ מינימום 1000 הודעות.
ככל הנראה אני סוגר איתו, בן אדם שמתחבר ישירות למכונת SMS של חברות הסלולר בארץ, עושה רושם של אדם ישר מאוד, לא מחזיק אנשי מכירות מצורעים. אתה מדבר עם בן אדם שיודע מה הוא עושה, ומכיר לפני ולפנים את כל המאכערים הישראלים בתחום (בזק המכובדת היא אחת מהם... הוא טוען שאין להם מכונה והם לוקחים שירות חיצוני כדי לשלוח SMS והם בעצם כמעט מתווכים)
לגבי קבלת SMS הוא רוצה 150 ש"ח בחודש על אחזקת קו, והוא שולח אליך את ההודעה באמצעות Http Get.
פורסם במקור בפורום CODE613 ב26/02/2014 17:13 (+02:00)
אין ספק שדוט נט זה דבר חכם, ו WPF חכם מאוד אפילו. אגב גוגל ניסו לעשות משהו לHTML שכביכול יחקה את WPF מבחינת לוגיקה (AngularJS) אבל הבנתי ממג'יקוד שעל פניו נראה שזה זולל משאבים כרוני, ותוקע את כל המחשב(!!!!) לפעמים, אז כנראה שהם לא הגיעו לרמת התיחכום הזו בעיבוד של הפקדים וכולי.
אני רוצה פשוט להודות על האמת, שהרבה פעמים אני מתפעל מהכישרון של היהודים המתכנתים שם 
(לגבי הגויים יש בעיה של "לא תחנם" אני לא מעוניין להסתבך עם זה :D) זה כדי לתקן את הקיתונות שאני שופך כל הזמן על מייקרוסופט מתוך אמוציות, ולתת גם פידבק למנהל הפורום שיודע להגיע לנקודות כל כך אמיתיות בתיכנות, באמת שפו!!! אז תודה על האשכול, ושכולם יהיו איכותיים כאלו
פורסם במקור בפורום CODE613 ב18/02/2014 21:59 (+02:00)
כנראה שסידרת הבדיקות שערכתי לא היו שיטתיות, בסוף מצאתי שעשיתי משהו לא נכון בקוד של הבדיקה, וזה הביא אותי לטעות ולחשוב שהבעיה בקוד היא בפונקציית ה API. אבל כרגע הכל עובד עם הפתרון שלך. ה Long הסופי הוא בסדר, היה צריך להחליף את הטיפוסים רק בתוך הארגומנטים.
יכול להיות שמה שכתוב באינטרנט זה נוגע למעשה איפה שאתה מעביר את הערכים לעוד API. אבל אם הערכים מטופלים ב vba זה חוזר להתנהגות רגילה של Long. הסיפור שם קשור לכתובות בזיכרון וסוגי דברים כאלו שממש קשורים לטרחני C++ ולא לאנשים אשר כמונו.....
פורסם במקור בפורום CODE613 ב12/02/2014 20:32 (+02:00)
כאן: יש משהו מעניין שמזכיר את הפתרון של רחמים, קוד אלגנטי בלי טבלאות זמניות...
פורסם במקור בפורום CODE613 ב09/02/2014 11:14 (+02:00)
אני לא יודע מאיפה להתחיל, ואם אני בכלל יכול לעזור. כי הגישה שלך שונה בתכלית משלי. אבל אנסה בכל זאת.
אני אציג את עמדתי בלי לנמק, כי הויכוח עשוי שלא להיגמר. קח מה שתרצה.
א. אין דבר כזה מספר תשלומים יש תאריך התחלה ותאריך סיום, כאשר הלקוח מחליט להאריך את הוראת הקבע, פשוט להגדיל את תאריך הסיום. כאשר ההו"ק בלי הגבלת זמן, משאירים תאריך סיום ריק.
ב. תיכנון גבייה הוא דבר די מיותר, כי בדרך כלל הוראת קבע נגזרת או מסכום חודשי קבוע שנקבע. או מהתחייבות כספית שהשודד סחט מהתורם והגיע איתו להסדר תשלומים. מה שקורה זה ככה, הוראת קבע עשויה להיגזר מ"יתרה" ועשויה להיגזר מהסכם חודשי ללא הגבלה. כמו כן, במקרה של "יתרה" אין צדק כלל להגדיר תשלומים מראש כי אם ההו"ק תחזור??? כמו"כ הוראת קבע שצמודה ליתרה צריכה להתחשבן באופן אוטומטי (מקסימום להגדיר תקרה לגביה במידה והיתרה גבוהה מכדי לשלמה בתשלום אחד)
ג. תיאור תשלום (תשלום1,תשלום2, ...), דבר מיותר לכאורה, וגם מספר תשלום, תשלומים זה טבלה עם תאריכים וסכומים. קישור להו"ק כן! אבל לא צריך מעבר לזה פירוט. מקסימום אם רוצים דו"ח ממסופר תמספר אותו עם פונקציות.
ד. אני לא הייתי קורא לטבלה של הגביה "חיובים" אלא "הכנסות" או "גביה", במשמעות של חיובים יש בהנהלת חשבונות מושג של חשבון חובה, וזה לא רלוונטי במקרה שנוצרה הכנסה.
פורסם במקור בפורום CODE613 ב03/02/2014 16:41 (+02:00)
אני מבין שכל הצורך ב ODBC הוא כאשר משתמשים באקסס כממשק וב SQL SERVER כמסד נתונים ואז ה ODBC מקשר בין הממשק למסד, אבל אם משתמשים ב WPF אז לא צריך כלל את ה ODBC. הלא כן?
כן בדרך כלל, odbc זה כאילו מימשק אונברסלי, מה שדוט נט עשו זה ספרייה ייעודית ל sql server ספרייה ייעודית ל my sql וכן הלאה, אבל לו יצוייר מסד נתונים שאין לו ספרייה לדוט נט, או שפת תיכנות כלשהי, שאין לה ספרייה למסד נתונים כלשהו, אז ישתמשו בחיבור ODBC, וזה המצב באקסס.
פורסם במקור בפורום CODE613 ב11/02/2014 00:28 (+02:00)
פורסם במקור בפורום CODE613 ב03/02/2014 12:07 (+02:00)
אחרי תקלות מוזרות כאלו, כדאי לעשות דחיסה ותיקון של מסד נתונים. או שמירה בשם ומחיקת הקודם, לפעמים גם העתק הדבק של הטופס עצמו בשם חדש ואז מחיקת הישן גם כן עובד.
יש הרבה זבל מאחורי הקלעים באקסס, השיטות הללו אמורות לנקות את זה.
פורסם במקור בפורום CODE613 ב22/01/2014 15:53 (+02:00)
מוסד צריך אבא ואמא לתוכנה, הוא לא יכול להסתמך על משהו שעשו אותו בשביל התחביב או בשביל האתגר. הוא ירצה שירות, הטמעה, שיהיה למי להתקשר כשהוא צריך, וחוץ מזה הצרכים מורכבים מאוד אחריות גדולה, כשמשהו קטן לא בסדר כל המערכת מושבתת. אז אם מישהו רוצה ויש לו עצבים להתקשקש עם מוסדות, זה כבר עבודה זה לא בדיוק אתגר נחמד...
פורסם במקור בפורום CODE613 ב26/01/2014 11:39 (+02:00)
Form.RecordSource = "Contacts"
במקום Contacts אתה יכול להכניס משפט sql איזה שתבחר, רק שהכל יהיה בתוך גרשיים.
פורסם במקור בפורום CODE613 ב19/01/2014 01:46 (+02:00)
אפשרות אחת זה ליצור קובץ accde שזה עובד כמו קובץ רגיל רק זה מקופמל (גם מגביר את הביצועים והמהירות)
אפשרות שניה זה לנעול את הקוד באמצעות סיסמה, בתפריט של visual basic tools>properies
פורסם במקור בפורום CODE613 ב09/01/2014 15:00 (+02:00)
GoTo
פורסם במקור בפורום CODE613 ב05/01/2014 23:40 (+02:00)
אם אתה צריך את זה לתצוגה בלבד (ועדיף שכך, כי זה יותר חסכוני לרשום שורה אחת לכל הכנסה שהיא בתשלומים.
כדאי לעשות את זה נטו עם שאילתה, בדרך הבאה. אתה עושה טבלה עם עמודה אחת שמכילה מספרים בלבד, נניח 24 רשומות שמכילות מספרים 1-24 שם אותה בשאילתה יחד עם טבלת התשלומים, ואז בעצם כל תשלום יופיע 24 פעמים (כי אין קשר גומלין בין הטבלאות), כדי להגביל את זה אתה עושה תנאי שהשדה מספר בטבלת המספרים הוא קטן או שווה לשדה מספר תשלומים בטבלת התשלומים. ואז הכפולות יהיו רק כמספר התשלומים. כעת אתה צריך גם לדאוג שהסכום יהיה חלקי התשלומים, והתאריך יהיה בתוספת של חודש כל רשומה (את זה אתה יכול לשאוב מהרשומה של טבלת המספרים להוסיף את החודשים על התאריך וכך לקבל את התאריך הנכון).
אם לא הובן, אעלה קוד וגם קובץ אם אפשרי.
בהצלחה.
פורסם במקור בפורום CODE613 ב05/01/2014 13:51 (+02:00)
שכבת הפלדה של הנתונים יכולה לכלול את הדטה ביס שיכיל נתונים בלבד ועוד כמה מחלקות קוד שיטפלו בנתונים, כך שזה יחסוך לזה המון זמן לנסות לעשות כל דבר בתוך ה SQL, תעשה בקוד ונגמר הסיפור. וכך גם לא תאבד את ההפרדה בין הממשק לשכבת הנתונים.
אתה צריך להבין משהו רבי רחמים, כאשר בונים פרוייקט נתונים, אתה לא יכול לדעת איך מחר או מחרתיים נרצה לעדכן ומאיזה שאילתה, עכשיו אם אתה עושה קוד שמטפל בכל מיני דברים, אתה צריך "לזכור" כל פעם שמעדכנים משהו, שזה יעבור דרך הקוד ההוא, וזה כבר בעייה של ארכיטקטורה, תאר לעצמך שהעסק מחליט להרחיב את פעילותו, ולאפשר ללקוחות לעדכן את הנתונים שלהם באמצעות אתר אינטרנט, ואתה למצער עשית איזה שהוא קוד שקשור בחבל הטבור לאינטרפייס של WPF או אקסס, או מה שזה לא יהיה. אתה מבין את המשמעות של זה כמה כתיבת קוד והמרת קוד אתה צריך כדי שזה יעבוד כמו שצריך. אבל אם כל הלוגיקה של הנתונים ארוזה בתוך הדטה בייס, אין לך מה לדאוג, והלקוח יכול אפילו לקחת מישהו אחר שיכתוב לו את הקוד של האתר, הרי סוף סוף כל מה שמעודכן בטבלה כלשהי, עושה את כל העבודה הנדרשת, על מנת לוודא ולאמת נתונים ברמת הבינה העיסקית. וזה עבודה אמיתית לטווח ארוך.
התחושה האישית שלי, שהנושא של UI הוא הרבה יותר נמצא בתהליכי התפתחות מואצים, מאשר המנועים האמיתיים, כגון דטה בייסים, וקוד ליבה. קח את שפת C ושפת SQL מאז שהמציאו אותן, לא נס ליחן ולא כהתה עינן, הן משרתות להערכתי 90 אחוז מכוח המיחשוב ברחבי העולם!!!! כל הפיתוחים שאנחנו רואים לא מפריעים בכלל למערכות קיימות, אלא רק משפרות ומשכללות. מאידך כמה מהמורות ותמורות עובר תחום ה UI בעשרים שנה האחרונות, כל אחד בא ומחסל את מה שעשה זולתו קודם לכן....
לכן אני תמיד ממליץ אם אתה רוצה שהמקצוע שלך יהיה יעיל ובר ביקוש למשך שנים ארוכות, תהפוך למומחה ב"מצרכי יסוד" של מיחשוב, כגון דטה בייסים, טכנולוגיית צד שרת וכדומה. אבל מי שהופך מומחה לפלטפורמה מסויימת, הוא "מהמר" שהיא תתפוס ותחזיק מעמד כמו וורדפרס או כיוצא באלו.
בכל אופן לא נסטה מהעניין, אתה צריך לספק ללקוח שלך דבר שאתה גאה בו למשך עשרים שנה קדימה לפחות, והדבר הכי טוב שאתה יכול לעשות בשביל זה זה הדטה בייס העוצמתי שלו. מבחינת UI הוא יוכל להחליף כל שנתיים מבחינתי, ולקחת גם חברות חיצוניות.
אם כבר, יש אפשרות להפעיל פונקציות CLR שכתובות בC# או VB, אבל זה כבר עניין אחר.
בכל מקרה השאיפה היא לעשות כמה שיותר בDB. זה נקרא שכבת פלדה.
דווקא זה קוסם לי הייתי צולל קצת לנושא הזה של יכולות CLR. אם יש מדריך פיקנטי, אשמח לקישור, בינתיים אני קורא את התיעוד הרישמי.
ואגב בעניין שלנו, אני כבר 80 אחוז באמצע לכתוב קוד גנרי שיעשה את העבודה של טבלת לוג שינויים, יש לי קצת בעיות עם הקוד אשאל בשאלה נפרדת.
תודה.
פורסם במקור בפורום CODE613 ב27/01/2014 15:59 (+02:00)