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

@nigun פחות שימוש בדרייברים לצורך טיפול בdb, קריאה מהדיסק הוא פעולה בסיסית של מערכת ההפעלה.

@שואף הוא מדביק את השם שמצא על המספר שחייג, וזה מופיע ברשימת השיחות הרגילה.

@שמואל4
יש לך 5 חלקי משפט
מלל
משתנה בPHONE
מלל
משתנה תאריך
מלל

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

לדוגמה

$a = 'abc '.$phone.' def '.$date.'gh';

ואת החלקים של המלל תכניס לתוך פונקציית iconv.

@bbn תוריד ממאפייני קיצור הדרך את הסימון הפעל כמנהל, אולי יעזור.

@מלא אם לא עוזר, תוסיף # מהצדדים.

@nigun אמר בהפניה מנתב בזק לשרת פרטי:

ניתוב IP משלוחה מסויימת לשרת שלי

מה הכוונה שלוחה מסויימת? מהו סוג השלוחה, SIP אנלוגי?
מה אתה מקבל מבזק?

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

@nigun אם תשים בשלוחה קופסת FXO תוכל להמיר את השלוחה לSIP, אבל מאוד לא מומלץ ומתכון לבעיות.

@בעזרתו אמר באקסס SQL: תנאי כפול (לא בני גד):

@Shmuel754 אמר באקסס SQL: תנאי כפול (לא בני גד):

השאלה מאיפה אתה מפעיל את השאילתה.

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

תשמור את השאילתה ללא תנאי, ובקוד תשלוף את השאילתה ותצמיד את התנאי מהפונקציה ותפעיל.

השאלה מאיפה אתה מפעיל את השאילתה.

תעשה פונקציה בVBA שיחזיר את הWHERE המתאים לתנאים.

תפעיל עדכון בעת כניסת שיחה, ועד שיגיע לתפריט, כבר יהיו נתונים.

נראה לי שיש שירות של הדואר ששולחים אליהם קובץ כתובות והם שותלים את המיקוד לרשומה.

--
לנוחותך, ניתן לשלוח אלנו קבצים לביצוע שרות להשתלת מיקוד/קוד חלוקה למייל mikudsupport@postil.com.
לקוחות דואר כמותי יכולים לפנות למנהלי הלקוח בדואר ישראל אשר יתנו מענה בנושא קבלת קבצי מיקוד וקודי חלוקה.
ראה אתר הדואר

והיות שהם שותלים מיקוד 9 ספרות הכולל קוד חלוקה והדורש עדכון פעם ברבעון, אפשר אחרי שמקבלים מהם קובץ, להוריד את קוד החלוקה ולהשאיר רק 7 ספרות מיקוד שזה תקין.

@אהרן למה לא להשתמש במשפט if באם התו קיים לפצל במיקום, ואם לא קח אותו שלם.

@nigun אני הגדרתי את הzen ל (50/60)+90, לא זוכר איפה ראיתי ומדוע, זה נתן לי זמן קרוב למה שמופיע בלוחות, לא משתמש למטרה הלכתית, אז זה הספיק לי.
אני בדקתי על מישור ולא ירושלים. בירושלים יש כאלו שלא מחשבים את כל הגובה 800 אלא חצי מזה 400.

@chagold תבדוק שורות אחרונות בmaillog.
תבדוק בפקודת mailq באם זה ממתין שם, ומה הסיבה.

@nigun
כיום יש כבר חוק שעון קיץ והזמנים קבועים, באם המערכת שלך מעודכנת, לא תצטרך לבצע שינוי שעון קיץ. הכל אוטומט.
הערך שאתה מקבל מהפונקציה הוא זמן ללא OFFSET של המיקום שלך, לכן חשוב לבדוק את האופסט של היום (בחורף 2 ובקיץ 3) ולהשתמש איתו בפונקציה sunset.

הzenith הוא חישוב גובה של המיקום לחישוב הזריחה/שקיעה, השימוש שלך הוא יותר למטרת תאריך ולא למטרה הלכתית, אפשר להתעלם מזה.

לפלא קארד, יש API המאפשר לשלוח מספר כרטיס ותוקף או טוקן.
https://gateway21.pelecard.biz/SandboxServices?selectedMethodId=62

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

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

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

@Shmuel754 כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.

אבל את כל זה אפשר לעשות גם בלי להפריד לשכבת נכסים ושכבת מודעות, אף אחד לא אמר למחוק מהדאטהבייס לגמרי את המודעה שנהפכה ללא רלוונטית או את הלוגים שלה
מה שתיארת זה audit log זה לא אמור להשפיע על מבנה הנתונים

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

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

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

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

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

ולמה כל זה חשוב, במבט לעתיד, כל מה שאתה עושה היום עבור לקוחות תרתי משמע גם מפרסמים וגם מתעניינים, אתה צריך להיות ערוך עם היסטוריה של הנתונים. לדוגמא, בעוד שנה יפנה אליך מתעניין שראה את הפרסום ויבקש אישור לבי"ד בד"ת שיש לו עם הצד השני, ויבקש אסמכתא שבתאריך הנ"ל זה פורסם בנתון זה, או שהמפרסם יתלונן אליך למה פרסמת ב-3,000 כשהמחיר שהוא רוצה זה 3500, אם תצליח להוכיח שזה מה שהוא הקיש בIVR (הרי לא רלוונטי הקלטת שיחה של ההקשות), ניצלת. או שמחר יקפוץ עליך מאן דהו ויטען שאתה מעתיק את המאגר שלו, אם תצליח להוכיח שקיבלת את הנתון יום לפניו מקור זה וזה ובגלל תאריך הקליטה במאגר שלך שאינו משתנה, כדין רשומה מוסדית, ניצלת.

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

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