השיטה אותה תיארתי כבר לא פועלת היום
כך שנכון לעכשיו לא ידוע לי על דרך בה אפשר לגשר בין ה API ל UI של ג'ימייל
פורסם במקור בפורום CODE613 ב19/04/2015 11:43 (+03:00)
השיטה אותה תיארתי כבר לא פועלת היום
כך שנכון לעכשיו לא ידוע לי על דרך בה אפשר לגשר בין ה API ל UI של ג'ימייל
פורסם במקור בפורום CODE613 ב19/04/2015 11:43 (+03:00)
הוא אומר שככל שהערכים שלך יחודיים כך גוברת יעילות האינדקס אם יש לך רק 1 או 0 בעמודה זה לא יעזור אבל אם כל ערך מהווה 10% מהטבלה זה שווה
מה שהוא עוד אומר זה פשוט לנסות את זה כי לפעמים האופטימייזר מתעלם מהאינדקסים אם הוא חושב שזה לא יעזור
פורסם במקור בפורום CODE613 ב24/02/2015 16:53 (+02:00)
א. כן, (בגירסאות קודמות יש משהו שנקרא PINTABLE וזה אומר ל SQL להעלות מראש טבלה מהדיסק לזיכרון, אני לא יודע על זה מספיק)
ב. כן, כמו טבלה רגילה רק אתה חייב ליצור את האינדקסים יחד עם הטבלה אי אפשר ליצור אינדקסים אחר כך, יש מגבלה על 8060 KB ל ROW, וצריך לבצע כמה שינויים ברמת ה DB
ג. אתה יכול להחליט אם אתה רוצה גיבוי לדאטה/לסכמה/בכלל לא בעת יצירת הטבלה, הוא מגבה את זה ברקע בצורה שהיא לא מאוד יעילה מבחינת שטח דיסק (בגלל שהוא מוכוון IN MEMORY אבל נותן יכולת לשחזר אם רוצים.
המידע שהיא מחזירה תמיד מדויק
OTLP כולל יכולת ליצור גם פרוצדורות שיתקמפלו ויעלו לזיכרון כ DLLים על מנת לשפר ביצועים
פורסם במקור בפורום CODE613 ב08/02/2015 12:25 (+02:00)
תמקד יותר את השאלה כי בלינקים שהבאת יש הרבה מאוד חומר . . .
בעיקרון זה אפשרות לטבלאות שיישבו רק בזיכרון ולא בדיסק (אבל יש כן גיבוי לדיסק) וזה נקרא In-Memory Tables
הרעיון שונה מאוד מ SQL רגיל כי הוא משתמש בשיטה שונה לסנכרון בין קריאות לכתיבות ולכן (כמעט) לא מבצע נעילות על ה DATA (במקום להמתין הוא נותן לכל אחד ורסיה אחרת של השורה)
וגם שומר את החומר בזיכרון במבנה יעיל יותר ולא בPages של 8KB (מוכוון קריאה כתיבה לדיסק) זה מייעל גם את האינדקסים והוא גם מעלה לזיכרון DLLים שמכילים את הלוגיקה ומבנה הנתונים על מנת שיהיה אפס I/O בזמן עיבוד השאילתה
בעת גיבוי מסד הנתונים הטבלאות נשמרות בגלל שיש גיבוי לדיסק ולכן גם ישרדו נפילה של השרת או של ה Process
פורסם במקור בפורום CODE613 ב08/02/2015 01:02 (+02:00)
התחלתי לעבוד לאחרונה עם keepass ומאוד חסרה האינטגרציה עם RDP, ואני, מפונק שכמותי, רוצה הכל בקליק אחד.
את הרעיון ראיתי כאן ושיפצתי אותו שיתאים לגירסת ה KEEPASS של היום (ולרמת הפינוק שאני מורגל אליה . . .)
cmd://"cmd.exe" /c cmdkey.exe /generic:TERMSRV/{URL} /user:{USERNAME} /pass:{PASSWORD} & start mstsc.exe /v:{URL} & timeout 2 & cmdkey.exe /delete:TERMSRV/{URL}
לשים את זה ב Properties -> Override URL
Works like a charm!
פורסם במקור בפורום CODE613 ב29/01/2015 12:24 (+02:00)
די פשוט. . .
עושים row_number שמים את רשימת השדות ב partition by ועושים where >1
פורסם במקור בפורום CODE613 ב04/01/2015 14:40 (+02:00)
ברגע שזה הפך לשאלה תיאורטית - זה התחום שלי . . .
בהחלט שישנו הגיון בכל זה - אבל הוא די מורכב - אנסה לעשות סדר
ישנן שתיים וחצי בעיות בדרך שבה ניסית לראשונה לפתור את הבעיה:
א. אתה מצפה לבצע מניפולציה על השורה הראשונה בכל מקום עבודה (להפוך את החודש ל 12) אבל את ה CASE שלך אתה שם רק בחלק השני של ה UNION והשורות האלו בכלל נבחרות בחלק הראשון שלו
ב. שכפלת את השדה FROMYEAR לשדה Y על מנת לבצע את המניפולציה על Y ולהשאיר את השדה המקורי לתצוגה ללא מניפולציה בכל השורות, מה שלא עשית בשדה TOMONTH ומכיוון שזו ריקורסיה זה גרם לכך שכשאתה מגיע לשורה האחרונה עבור מקום העבודה הערך בשדה TOMONTH נלקח מהשורה הקודמת שעשתה עליו מניפולציה ל 12 - ז"א התנאי ב CASE עובד אבל הערך שביקשת ממנו להביא הוא כבר לא הערך המקורי
ג. לא אהבתי את התת שאילתה אבל זה כבר עניין של טעם
הפתרון שלי הוא כזה
א. לשים באופן קשיח את החודש 12 ב TOMONTH בחלק הראשון של ה UNION ולשים 1 קשיח ב FROMMONTH בחלק השני של ה UNION
ב. להפריד את FROMMONTH לשדה נוסף שלא יבוצעו עליו מניפולציות לאורך הריקורסיה ואותו לשים בתנאי
ג. לשים Y+1 בכל השוואה ולחסוך את התת שאילתה
מה שאני חייב להודות שהפתרון של CASE בשאילתה הסופית הוא לא רע בכלל, לכן אני אוהב שהעניינים הופכים להיות עקרוניים ואפשר להתפלפל בלי לתת למציאות להפריע :lol:
הדוגמה שלי:
--טבלה שאמורה להכיל את הנתונים ולעבד אותם לפני ההכנסה סופית למסד הנתונים
declare @WorkingPlacesDetailed table (ID int IDentity(1,1) ,FromYear int, FromMonth int, ToYear int,ToMonth int, WorkingPlaceID int,WorkingPlaceName nvarchar(500),DeductionsNumber int,ParentID int);
--ממלא את הטבלה בנתונים לדוגמא
insert into @WorkingPlacesDetailed (FromYear , FromMonth , ToYear , ToMonth ,WorkingPlaceName)
Values(2005,5,2010,9,'פורום חרדי לעניני תיכנות') ,(2010,11,2013,4,'ארגון דעאש');
--מוסיף רשומה לכל שנה בטבלה זו עצמה על סמך ההפרש בין השנים
with cte as
(select ID, FromYear y,FromMonth ,ToYear, ToMonth m, 12 ToMonth, FromYear,WorkingPlaceName from @WorkingPlacesDetailed w where w.FromYear<w.ToYear
union all
select ID,
y+1 y,
1 FromMonth,
ToYear,
m,
(case when y+1 = ToYear then m else 12 end) as ToMonth,
FromYear,WorkingPlaceName
from cte w where w.y+1 <= w.ToYear)
select y as Year,FromMonth , ToMonth , WorkingPlaceName ,ID as ParentID from cte Order by y
פורסם במקור בפורום CODE613 ב16/12/2014 02:00 (+02:00)
כמו שזה נראה זה ללכת עם ראש בקיר
תנסה אולי לעשות INJECTION לדף ל POLYFILL הזה
פורסם במקור בפורום CODE613 ב17/12/2014 10:28 (+02:00)
לווינדוס נראה לי זה:
https://github.com/charlesw/tesseract
פורסם במקור בפורום CODE613 ב30/11/2014 14:16 (+02:00)
הביעה היא שאתה עושה COUNT על MAX והוא לא יודע לעשות אגרגציות מקוננות.
אני מבין מה אתה רוצה להשיג אבל זה יעבוד לך רק עם תת שאילתה ב JOIN שתביא את ה MAX עבור כל רשומה
פורסם במקור בפורום CODE613 ב25/11/2014 10:32 (+02:00)
SQL הוא טיפוס דרמטי, יש לו יתומים וקורבנות ונעילות מתות וכו'
אז קודם כל זה לא קשור לעדכון אינדקסים בכלל . . .
DEADLOCK קורה במצב שבו שתי טרנזאקציה א נועלת את טבלה A וטרנזאקציה ב נועלת את טבלה B
ואז טרנזקציה א מנסה לגשת ל B והיא כמובן מחכה שהיא תסיים ותשחרר את B אבל אז טרנזקציה B מנסה לגשת ל A
אז B מחכה ל A ו A מחכה ל B אז SQL בוחר אקראית אחד מהם ופשוט מעיף אותו עם ההודעה הנ"ל ואז השני יכול להמשיך
ברגע שקיבלת את ההודעה המשתמש השני פשוט ממשיך לדרכו ואתה הקורבן . . .
בתכנון נכון זה מצב נדיר ביותר ויש דרכים לצמצם את זה
לדוגמה תמיד לגשת לאובייקטים באותו סדר ולעשות רק טרנזאקציות קצרות
או למנוע פתיחת טרנזקציות שידוע שהם בעייתיות במקביל ברמת אפליקציה (בעייתי כשיש הרבה יוזרים)
אפשר להתעסק עם ה ISOLATION LEVEL אבל זה למי שמבין מה הוא עושה
עיי"ש :
פורסם במקור בפורום CODE613 ב20/11/2014 15:50 (+02:00)
ישנה אפשרות אחרת, לא יודע מי המציא אותה (אם בכלל).
ממירים כל מילה למילה מתומצת לפי כללים מסויימים.
כגון:
שבת=שבט
או:
פונוביז=פנבז
פוניבז=פנבז
וכמובן:
פונוביז'=פנבז
פוניבץ'=פנבץזה מאוד מקדם.
צריך לשאול את דעת ארכיטקסט.
בעברית זה רעיון אבל באנגלית זה כמעט לא ישים.
פורסם במקור בפורום CODE613 ב13/11/2017 15:26 (+02:00)
לא ממש ירדתי לסוף דעתך אבל ברפרוף נ"ל שהתחביר של Count+Distinct יעשה לך טוב
SELECT COUNT(DISTINCT EmailAddress), -- Count unique Emails
COUNT(DISTINCT EmailAddress + ';' + CampaignID), -- Same with two columns
COUNT(DISTINCT (CASE WHEN CampaignID = 68 THEN EmailAddress END)) -- Count unique Emails for specific campaign
FROM BatchInfoView
פורסם במקור בפורום CODE613 ב28/10/2014 00:20 (+02:00)
משהו כזה?
SELECT Creator,
SUM(CASE WHEN CAST(CreateDate AS DATE) > CAST(GETDATE() AS DATE) THEN TotalSC ELSE 0 END) AS Future,
SUM(CASE WHEN CAST(CreateDate AS DATE) <= CAST(GETDATE() AS DATE) THEN TotalSC ELSE 0 END) AS Past
FROM PO_Header
GROUP BY Creator
פורסם במקור בפורום CODE613 ב27/10/2014 12:48 (+02:00)
גם אני נתקלתי בזה בעבר - לצערי התשובה היא לא
לגבי הטבלה (אם הבנתי נכון את השאלה) נסה להשתמש בפקודת SQL ולא ב Designer, ה designer לפעמים יוצר מחדש את הטבלה ללא צורך אמיתי
פורסם במקור בפורום CODE613 ב23/09/2014 10:33 (+03:00)
הפורמט היחיד שמדפסות מכירות זה PostScript תכל'ס כל מה שתשלח למדפסת יתורגם ל PS על ידי הדרייבר
יש לך שתי דרכים:
להעלות את הדף בקונטרול של WebBrowser ולשלוח פקודת הדפסה
לתרגם HTML ל PS ואז לשלוח ישר למדפסת את ה PS
פורסם במקור בפורום CODE613 ב21/09/2014 13:38 (+03:00)
התשובה היא שאי אפשר
בד"כ במצב כזה משתמשים בשם שמרמז על משמעות הפוכה לדוגמה אם אתה רוצה לדעת אם כרטיס פעיל וברירת המחדל היא שכן אז במקום משתנה של IsActive שיאותחל כFalse קוראים לו IsInactive ואז זה מצביע על התוצאה הרצויה
פורסם במקור בפורום CODE613 ב02/09/2014 13:06 (+03:00)
אני מסייג את דברי מכיוון שאני ואקסס לא חברים . . .
Navigate הוא אסינכרוני נסה בלי Navigate (אולי לא יהיה לך DOCUMENT) או באירוע NavigationCompleted או משהו דומה
פורסם במקור בפורום CODE613 ב28/08/2014 16:24 (+03:00)
אפשר טבלה אחת ענקית, ועמודה של שם הטבלה לא???
נכון, לפעמים אני עושה כך ולפעמים כך הכל לפי משתני הסביבה
פורסם במקור בפורום CODE613 ב31/08/2014 00:58 (+03:00)
תודה על המחמאות
האמת שזה חלק מתוך פרויקט שאני עובד עליו של DAL ל WINFORMS
אני מקווה שבקרוב אוכל לשחרר עוד
פורסם במקור בפורום CODE613 ב26/08/2014 14:01 (+03:00)