תן לי להבין.. שאתה מריץ שאילות בלוקאלי הם עובדות יותר מהר מאשר שאתה פועל דרך remote?
זה מאוד מוזר הסיפור שאתה מספר..
ממש ככה.
אני מדבר איתך על רמות הזויות, שאילתת אינסרט לרשומה בודדת לוקחת 40 שניות... סיריסלי :x
פורסם במקור בפורום CODE613 ב02/08/2014 23:49 (+03:00)
הטכנאי של הארגון טוען שהוא בדק הכל והכל מבחינתו תקין כלומר מהירות תקשורת וכו', יש איזה צוואר בקבוק אחר שאפשר לבדוק???
זה לא קורה כל הזמן אלא בזמנים מסויימים, וקשה מאוד לדעת מה בדיוק הגורם.
רוב הסיכויים שזה קשור לאינטרנט קלמנטינה...
פורסם במקור בפורום CODE613 ב02/08/2014 22:56 (+03:00)
טוב מבחינה מעשית עשיתי את זה כבר באקסס לדאבוני, באמצעות טבלאות מקושרות, אך עדיין אשמח לקבל מידע אודות השגיאה הזאת.
פורסם במקור בפורום CODE613 ב31/07/2014 18:24 (+03:00)
שלום לכולם
כהמשך לעיקרון "טוהר ה SQL" שנזכר כאן בשיתופיה. השיגעון הבא, הוא לעשות טבלה שתכיל את כל דקות היממה, אך משום מה משפט אינסרט לא מצליח לי (משפט הסלקט עובד מצויין ומבוסס על שדה כלשהו בקלנדר שמכיל רצף של מספרים עד 55 אלף).
זאת השגיאה: Truncated incorrect time value: '6000'
insert queuing_system.times (time_value)
SELECT cast(serial_number as time) from calander
where
serial_number MOD 100 = 0 and cast(serial_number as time) is NOT NULL
קוד ליצירת הטבלה:
CREATE TABLE `times` (
`time_value` time NOT NULL,
PRIMARY KEY (`time_value`),
UNIQUE KEY `time` (`time_value`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='תצוגה של כל הדקות במהלך היום';
פורסם במקור בפורום CODE613 ב31/07/2014 18:02 (+03:00)
כשאין ברירה אין ברירה.
פורסם במקור בפורום CODE613 ב01/08/2014 09:24 (+03:00)
צר לי לאכזב אותך אבל כל עוד רוחב עמודות מוגדר 0ס"מ אין סיכוי.... לצערי הרב.
אני עשיתי במקרה כזה שיש ביקורת בעת בחירת ערך שהוא לא מאפשר לו לבחור ערך לא נכון, אבל להגביל את הרשימה עצמה זה גורם לאפקט הנ"ל ללא כל יכולת לעקוף אותו.
פורסם במקור בפורום CODE613 ב31/07/2014 01:18 (+03:00)
עניתי לך בפרטי.
פורסם במקור בפורום CODE613 ב28/06/2015 16:12 (+03:00)
באיזו שפה/פלטפורמה אתה כותב? איזה מסד נתונים יש לך?
בעיקרון יש לך שם 150 שנה לוח שנה, שכל יום מקבל רשומה, ויש לך ערך תאריך לועזי, כך שאת כל המניפולציות שיש לת. לועזי אתה יכול לקבל בלידאין, ולהרוויח על הדרך את התאריך העברי שהוא התוצאה. כמו"כ יש לך שם ערכים מספריים המייצגים את השנה החודש והיום העברי. אם תכתוב כאן מטרה ברורה, אכתוב לך משפט SQL שנותן כל תוצאה שתרצה.
בהצלחה.
פורסם במקור בפורום CODE613 ב28/06/2015 12:56 (+03:00)
גירסת mysql:
ליצירה:
CREATE TABLE `calander` (
`gregorian_date` date NOT NULL,
`full_hebrew_date` varbinary(14) NOT NULL,
`serial_number` int(11) NOT NULL,
`hebrew_number_day` tinyint(4) NOT NULL,
`hebrew_day` varchar(2) NOT NULL,
`hebrew_number_month` tinyint(4) NOT NULL,
`hebrew_month` varchar(5) NOT NULL,
`hebrew_number_year` smallint(6) NOT NULL,
`hebrew_year` varchar(5) NOT NULL,
`day_of_week` tinyint(4) NOT NULL,
PRIMARY KEY (`gregorian_date`),
UNIQUE KEY `UK_calander_serial_number` (`serial_number`),
KEY `IDX_calander_full_hebrew_date` (`full_hebrew_date`),
KEY `IDX_calander_hebrew_day` (`hebrew_day`),
KEY `IDX_calander_hebrew_number_day` (`hebrew_number_day`),
KEY `IDX_calander_hebrew_number_month` (`hebrew_number_month`),
KEY `IDX_calander_hebrew_number_year` (`hebrew_number_year`),
KEY `IDX_calander_day_of_week` (`day_of_week`),
KEY `IDX_calander_hebrew_month` (`hebrew_month`),
KEY `IDX_calander_hebrew_year` (`hebrew_year`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='לוח שנה עברי ולועזי';
לייבוא החומר:
calander.rar
פורסם במקור בפורום CODE613 ב31/07/2014 00:38 (+03:00)
לתועלת הציבור אני מעלה לכאן טבלה פשוטה אך שימושית מאוד מאוד מאוד מאוד, בשאילתות מורכבות, (מי שהראש שלו בנוי בצורת מסד נתונים יחסי, קשה מאוד להשתחרר מזה, ולהשתמש בקוד כדי להשלים משהו זה לפעמים דבר די מרתיח, כשהאופציה שכנגד היא להשתמש ב SQL טהור) במהלך 5 השנים האחרונות זה הקל עלי מאוד, בפרט במניפולציות על תאריכים עבריים.
זאת טבלה של לוח שנה ל 150 שנה מתחיל בשנת תש.
לוח שנה עברי.rar
גירסת mysql בדרך.
פורסם במקור בפורום CODE613 ב30/07/2014 23:42 (+03:00)
הבעיה היא שהטובים הם בתשלום . . .
לא נראה לי שזה ירתיע את הארגון, הרי לא מדובר באלפי דולרים, אלא במאות לכל היותר, מן הסתם שעות עבודה שייחסכו ממני יכסו את זה.
אז אם יש לך אחד מה"טובים" שבאמת התנסית בהם, אשמח לשיתוף.
פורסם במקור בפורום CODE613 ב31/07/2014 00:53 (+03:00)
תודה על ההצעה, עוד לא בדקתי לעומק, אולי כדי לחסוך זמן, הניהול הזה מחובר בוורידים שלו ל CRM המקומי, למידע על לקוחות, העדפות, שעות של העובדים, חופשות ושאר ענינים עד אין חקר. הציפיה שלי היא שהקלנדר יוכל "להכיל" את המידע, לא שיהיה כל כך חכם כי זה התפקיד של הדטה בייס בתפיסה שלי, אבל אי אפשר לבנות רק על פתקים צהובים, בשביל זה יש גוגל קלנדר והוא לא ממש יעיל...
פורסם במקור בפורום CODE613 ב31/07/2014 00:52 (+03:00)
איך יהיה אפשר לדחוף תורים???.
ברמת הדטה בייס זה בנאלי, שאילתת update פשוטה שמוסיפה 10 דקות לכל ערך תאריכי, על פי התנאי שלך.
ברמת המימשק זה באמת צ"ע וזה די תלוי מימשק.
אם הולכים עם מימשק זול קרי: אקסס, אין סיכוי לפונקציונליות של גרירה והשלכה, שעוד תהיה "כה חכמה" עד כדי כך שתעשה שאילתת update בהתאם לגרירה וההשלכה.
פורסם במקור בפורום CODE613 ב31/07/2014 00:35 (+03:00)
שלום לכולם
מערכת לזימון תורים במרפאה, מסד הנתונים די פשוט, לכל עובד יש ימים בשבוע ושעות עבודה, טבלה נוספת היא התורים שמשעה X עד שעה Y לכל מטופל.
השאלה הגדולה היא המימשק, והתקשורת שלו מול מסד הנתונים. אני לא יודע אפילו איך להתחיל, בראש האקססאי/דטה בייסי שלי אני מצייר לנגד עיני טבלה, שתפקידה להציג את כל השעות האפשריות (כל תור הוא מוגדר 10 דקות) לכל עובד ורק היכן שיש תור מוזמן בטבלת התורים "הנקייה" (כלומר שמכילה רק את הזמנים שבהם באמת יש תורים) היא מציגה שהתור תפוס. ואז הפקיד רואה מתי יש חלונות ומזין לתוך טבלה זו נתונים, אלו בתורם נכנסים לטבלה "האמיתית" באמצעות טריגר.
בקיצור הרעיון שלי הוא בעצם לגרום לדטה בייס (מדובר אגב ב mysql במקרה הזה כי צריך סינכרון עם מרכזיית אסטריסק) לייצר טבלה ענקית של נניח, חודש קדימה. וזאת תהיה הטבלה שאיתה משתמש הקצה כגון פקידה יתממשק. טבלה זו תיווצר בכל פעם מחדש, בעקבות התאריכים המתקדמים לפי החוק של איינשטיין שהזמן מתקדם כל הזמן (תסתכלו על השעון ותראו שהחוק הזה נכון...)
אם יש למישהו רעיון למימשק שהוא חצי מוכן או משהו אשמח לשמוע. כל פלטפורמה תהיה טובה, בתנאי שתחסוך עבודה.
פורסם במקור בפורום CODE613 ב30/07/2014 21:33 (+03:00)
הרצתי אותו עכשיו על תיקייה שיש בה 43K קבצים, בהתחלה הוא נתן מידע הגיוני אך החל מרשומה 460 בערך, פתאום כל הקבצים אותו גודל ואותו תאריך שינוי בדיוק (על השניה!!!) השאילתה עצמה לקחה 6 דקות....
לא ברור מה הסיפור, אין ברירה, נעשה את זה דרך קוד רגיל בלי SQL.
פורסם במקור בפורום CODE613 ב28/08/2014 14:24 (+03:00)
איך אני מקבל את הערך
אני מעדיף להשתמש בזה רק כשאין ברירה אחרת, אני מאמין באמונה שלימה שכשם ש dbo.xp_fileexist עושה עבודה מצויינת ומכוונת קבצים, כך גם לגבי שאר מאפייני הקובץ..
פורסם במקור בפורום CODE613 ב29/07/2014 14:36 (+03:00)
5566brs את זה כבר ראית???
פורסם במקור בפורום CODE613 ב06/01/2016 23:45 (+02:00)
שלום לכולם, הואיל ואינני יודע כמעט כלום על נוד, ורוצה ללמוד, אין דבר טוב יותר מלכתוב מדריך למתקדמים בלבד!!!! על מנת להתחיל וללמוד את התחום הזה. :lol: :lol: :lol:
אז בואו ונתחיל, מה זה בעצם NodeJS
את מה שכתוב בויקיפדיה כולם יודעים, לא צריך לחזור על זה. הרעיון המרכזי של NodeJS זה לממש את שפת ג'אווה סקריפט בצד שרת, השפה שעד שנת 2009 נחשבה לרכושו של הדפדפן בלבד, כעת ממומשת בצד השרת בצורה מדהימה!! אנשים המכורים לג'אווה סקריפט, יכולים לנשום לרווחה, מימוש קוד מורכב של צד שרת, אפשרי גם אפשרי באמצעות היכולות המטורפות של java script. (את האמת שאני גם לא מי יודע מה יודע ג'אווה סקריפט, ולכן אני צריך לכתוב על כך מדריך נפרד, אבל כרגע אני מנסה לתאר את העובדות כפי שהן מהחומרים שקראתי)
כמה דברים מעניינים שיש ב node js אחד מהם זה למשל היכולת ליצור שרת עצמאי, על ידי פונקציה פשוטה בשם createServer יש לנו שרת מוכן ומזומן המאזין לאיזה פורט שנגיד לו, בלי שום צורך להפעיל שרת אפאצ'י וכדומה.
היתרון הבולט ביותר שאנו רואים ב nodejs היא הצמיחה המרשימה של ספריות הקוד שלה, נכון לרגע זה יש לה 85,595 ספריות קוד, כ 6 מיליון הורדות ביום, וכ 357 מיליון הורדות בחודש. אם נשווה את קצב הצמיחה שלה על ציר זמן, זה עוקף כל דבר שאנחנו מכירים מעולם התוכנה אי פעם... עובדה.
אז בדיוק מהסיבה הזאת אנחנו לא רוצים להישאר פרימיטיביים, וחייבים להיכנס לענינים. קדימה ללימודים.
אם יש כאן טעויות ואי דיוקים, או אם אני כותב כמו עינב גנד גלילי, אני מצפה מ magicode שיתקן אותי, כי הוא מרא דשמעתתא של node js. עיקר המטרה שלי במדריך הזה זה לעורר את עצמי ואת אחרים עורו ישנים משנתכם, העולם מתקדם, ובעוד עשר שנים מי שלא יודע node עלול למצוא את עצמו מקרצף פנלים אצל מי שיודע node. אז חבל, בואו ונתעורר בזמן לפני שהאפוקליפסה תתפוס אותנו לא מוכנים. בכלכלת הדור הבא המתכנתים ישלטו בכל תחום ותת תחום, ולא תהיה שום פינה בעולם שבו לא יבוא מתכנת וימלוך על מי שאינו מתכנת.
כדי להתחיל לעבוד עם node נצטרך להתקין את החבילה הבסיסית, ואת הספרייה express אקספרס, מדריכים איך להתקין וכו' יש מיליון באינטרנט, הספרייה אקספרס היא ספרייה שכתב אותה איזה בחור צעיר, והיא הכי בסיסית בנוד, כמעט ואי אפשר לעבוד עם נוד בלעדיה.
את ההמשך אני ממתין לקרוא ממי שמתמחה באמת ב node ולא מאיש אשר כמוני. :lol: :lol: :lol:
פורסם במקור בפורום CODE613 ב27/07/2014 23:50 (+03:00)
אם זה יהיה לתוך PDF ולא לתוך tiff השאלה משתנה כליל? או שזה עדיין משהו מורכב??
דווקא את השאלה הזאת יש הרבה באינטרנט, עדיין לא הספקתי לי לברור קוד איכותי. אני גם צריך שזה יהיה לפי קווי אורך רוחב ולא בשורת הטקסט כמו שרוב הקודים עושים.
פורסם במקור בפורום CODE613 ב29/07/2014 09:29 (+03:00)
מהשאלה קצת משמע שזה משהו שכל יום צריך להוסיף, אז אולי באמת כדאי ללכת על החלק התיכנותי בעניין.
זה לא רק כל יום להוסיף, זה אמור להתבצע ללא מגע יד אדם, כלומר מנגנון שיבדוק אחת ל... מה המצב, ואולי אפילו ע"י הצפת אירוע כל שהוא, הטפסים מגיעים בפקס או מייל, או משהו כזה, הם אמורים להיות מוזרמים בצנרת האוטומטית לתוך הדטה בייס, ובדרך לעבור "חיתום" אקיצר כמו פס ייצור.
אני חושב שרק מחלקות גרפיקה עצומות מימדים מסוגלות להתמודד עם המטלה האינסופית הזאת. אני רק יכול להגיד לך שעד היום בארגון הזה מדפיסים, מחתימים וסורקים שוב....
פורסם במקור בפורום CODE613 ב27/07/2014 23:24 (+03:00)