none
trigger שאלה לגרי ולכולם :) RRS feed

  • שאלה

  •  

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

    תהפוך להיות בתוך טרנזקציה? כלומר אם עשית פעולה  update (בלי begin tran) הטריגר יקפוץ יכניס את פעולת ה update    שלי  לתוך טרנזקציה

    ןאם יכשל הוא יעשה rollback back  גם לפעולה שבעקבותיה קפץ הטריגר כלומר ה update  על הטבלה?? מקווה שהייתי  ברור מעבר לזה אם זה עובד ככה

    אז די מאכזב לא?  כלומר אז מה אם הטריגר נכשל יכול להיות שבטריגר בכלל לא מתבצעת פעולה על הטבלה שבעקבותיה קפץ הטריגר .... ואני רוצה  שהפעולה

    שבעקבותיה קפץ הטריגר תצליח ( מקווה שלא חפרתי :))

    עכשיו נתקדם - יצרתי  כבר את הטריגר   והוא נפל  אז למה אי אפשר לשהתשמש ב try catch  כדי לתפוס את הנפילה

    ולרשום אותם ללוג אם משהוא הצליח אשמח לשמוע איך הוא עשה זאת :)

    תודה שרון

     

     

     

     

    בנוסף :

     

     

    יום שלישי 13 ספטמבר 2011 07:20

תשובות

  • אהלן גיבור,

    אני מניח שאתה מכניס את הרשומה שנכנסה לטבלה אחרת לצורך Audits או כבסיס לפעולה אחרת.

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

    זה סנריו הרבה יותר גרוע !!!

    לדוגמא:

    רשומה חדשה, או עדכון רשומה, בטבלת לקוחות מכניסה לטבלת Client_Audits ע"י טריגר.

    טבלת Client_audits מהווה בסיס לטרנספורמציית הלקוחות ל- DWH.

    נפילה של הטריגר תייצר מצב שבו יש לי לקוח פעיל במקור שלא יהיה מוכר ב- DWH.

    לא נעים ואף יכול לגרום לבעיות רבות עקב בעיית Data integrity קשה.   

    בסה"כ מהנפילה למדתה:

    1. שיש לך בעיה בטבלת ה- "Audits", מניח שתיקנתה בקלות.

    2. שטריגר מוכל בתוך הטרנזקציה של המשפט שהפעיל אותו.

    3. את ההיגיון מאחורי הנושא.

    מזל שיש לפעמים תקלות :)

    יום טוב 


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 10:38
  • הי שרון,

    כל פעולת DML ו- DDL כגון Insert'Update\Delete או Create index\ Alter table וכו' ... "נעטפות" בטרנזקציה.

    נניח שיש לך פרוצדורה, ללא Begin Tran, שמבצעת פקודת Insert.

    בפועל ה- Sequel Server עוטף אותה בטרנזקציה ומבצע את הפעולה.

    נניח שעל הטבלה שאליה אתה מכניס את הנתונים בפקודת ה- Insert יש trigger for insert הפקודה ב- Trigger נכנסת לאותה טרנזקציה.

    בקיצור:

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

    טריגרים מוכלים בתוך הטרנזקציות הנ"ל, כלומר" במידה ויש לי פעולת Insert לטבלה שיש עליה טריגר ע"מ להגיע ל- Commit גם פקודת ה- Insert וגם הטריגר צריכים להסתיים בהצלחה.

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

    נניח שיש לך פקודת Insert ואחריה פקודת Update ואתה רוצה "לבצע" Commit רק במידה ושני הפקודות עברו בהצלחה אז תצטרך לעטוף בצורה מפורשת את הקוד ב- Begin\Commit transaction.

    לגבי ה- Try Catch אני תכף יסביר ....

    מקווה שההסבר מספיק ברור.

    יום טוב,

      


    אסף שלם
    • הוצע כתשובה על-ידי pituachMVP, Editor יום שלישי 13 ספטמבר 2011 09:39
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 08:50
  • הי,

    דבר נוסף לגבי ה- "אז די מאכזב לא?" 

    ה- SQL Server מבטיח לך Recovery של כל הפקודות שעברו Commit גם אחרי נפילת המערכת.

    מה היה קורה אילו פקודת ה- Insert היתה מצליחה ובזמן פעולת הטריגר היתה נפילה לשרת??? היתה מקבל מידה לא אמין.

    כלומר, הייתה מצפה לראות את הביצוע של פקודות הטריגר מכוון שפקודת ה- Insert הצליחה, לא?

    וע"מ לשמור על אמינות המידה ה"מנוע" עוטף את פקודת ה- Insert וה-טריגר בטרנזקציה אחת.

    לאחר הנפילה הוא מאחזר את הנתונים של כל הטרנזקציות שעברו Commit אך עדין לא נרשמו ב- Data Files מה- Transaction Log ומכוון שפקודת ה- Insert לא עברה Commit עקב הנפילה בזמן הרצת הטריגר אתה תקבל, בזמן עליית המערכת, את המידה בצורה האמינה ביותר.

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

    היתה פותח את טבלה Y רואה את הערך 1 ובטבלה X לא הייתה מוצא נתונים ): ... הרבה יותר גרוע מנפילה של ה- Insert.

     

     

    מקווה שגם זה ברור ...

     

      


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 09:01
  • הסבר יפה של אסף...
    אני רוצ להוסיף נקודה לגבי ה "אז די מאכזב" ודוגמה להמחיש זאת

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

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

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

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

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


    • נערך על-ידי pituachMVP, Editor יום שלישי 13 ספטמבר 2011 09:37
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 09:15
    מנחה דיון
  •  קודם כל תודה רבה על התגובות המהירות והטובות - אבל קחו את המצב הבא ותגידו לי מה דעתכם:

    אני מפעיל טריגר על  הכנסת רשומה חדשה  לטבלה - לאחר הכנסת אני שולף מטבלת inserted   את הרשומה

    החדשה שנכנסה  בתוך הטריגר ומכניס את הרשומה לטבלה אחרת שקיימת במסד הנתונים וטבלה האחרת   ונפלתי על primary key

    אז אתם אומרים  שאם ה  insert   שבעקבותיו הופעל הטריגר צריך גם להתבטל.... מה זה לא הזוי קצת??

    שרון

     

    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 10:22
  • הי,

    ועכשיו לגבי, Try Catch.

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

    Create table dbo.Clients
    (
    	clId	int not null identity(1,1),
    	clCode	int not null,
    	clName	varchar(100)	
    )
    Go
    
    Create table dbo.Client_Audits
    (
    	claId				int not null identity(1,1),
    	-- The primary key will raise an eror if the same client will be inserted more than once
    	claClientCode		int not null Constraint PK_Client_Audits_claClientCode Primary Key, 
    	-- 
    	claName				varchar(100) not null,
    	claChangeDateTime	datetime not null	
    )
    Go
    
    Create trigger dbo.trg_a_i_Clients
    On dbo.clients
    for insert
    As
    	Insert  dbo.Client_Audits (claClientCode, claName, claChangeDateTime)
    	Select clCode, clName, GETDATE()
    	from inserted  
    
    Go
    
    Create procedure dbo.usp_Clients_Insert
    	@ClientCode int,
    	@ClientName varchar(100)
    As
    Begin
    	Insert dbo.Clients (clCode, clName)
    	Select @ClientCode, @ClientName
    End
    
    Go 
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    Select * from dbo.Clients 
    Select * from dbo.Client_Audits  
    
    -- Let Add the same client and see the resulsts
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    Select * from dbo.Clients 
    Select * from dbo.Client_Audits  
    
    /*
    	The duplicate insert did not affected the clients table, since there is no unique constraint on the clCode column
    	but did affect the  Client_Audits table that has a constraint, PK, and that rolled back the "internal" transaction
    */
    
    -- Lets try to avoid the scenarion with try\ catch blocks
    Alter trigger dbo.trg_a_i_Clients
    On dbo.clients
    for insert
    As
    Begin try	
    	Insert  dbo.Client_Audits (claClientCode, claName, claChangeDateTime)
    	Select clCode, clName, GETDATE()
    	from inserted  
    End Try
    Begin Catch
    	Print 'Error Occured' 
    End Catch
    Go
    
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    /*
    	Has you can see in the result, the error did catched and handeled in the catch block; but the batch
    	has been aborted and the internal transaction has been rolled back.    
    */ 
    
    
    
    
    
    
    
    
    
    
    
    
    
    

     


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 15:03

כל התגובות

  • הי שרון,

    כל פעולת DML ו- DDL כגון Insert'Update\Delete או Create index\ Alter table וכו' ... "נעטפות" בטרנזקציה.

    נניח שיש לך פרוצדורה, ללא Begin Tran, שמבצעת פקודת Insert.

    בפועל ה- Sequel Server עוטף אותה בטרנזקציה ומבצע את הפעולה.

    נניח שעל הטבלה שאליה אתה מכניס את הנתונים בפקודת ה- Insert יש trigger for insert הפקודה ב- Trigger נכנסת לאותה טרנזקציה.

    בקיצור:

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

    טריגרים מוכלים בתוך הטרנזקציות הנ"ל, כלומר" במידה ויש לי פעולת Insert לטבלה שיש עליה טריגר ע"מ להגיע ל- Commit גם פקודת ה- Insert וגם הטריגר צריכים להסתיים בהצלחה.

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

    נניח שיש לך פקודת Insert ואחריה פקודת Update ואתה רוצה "לבצע" Commit רק במידה ושני הפקודות עברו בהצלחה אז תצטרך לעטוף בצורה מפורשת את הקוד ב- Begin\Commit transaction.

    לגבי ה- Try Catch אני תכף יסביר ....

    מקווה שההסבר מספיק ברור.

    יום טוב,

      


    אסף שלם
    • הוצע כתשובה על-ידי pituachMVP, Editor יום שלישי 13 ספטמבר 2011 09:39
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 08:50
  • הי,

    דבר נוסף לגבי ה- "אז די מאכזב לא?" 

    ה- SQL Server מבטיח לך Recovery של כל הפקודות שעברו Commit גם אחרי נפילת המערכת.

    מה היה קורה אילו פקודת ה- Insert היתה מצליחה ובזמן פעולת הטריגר היתה נפילה לשרת??? היתה מקבל מידה לא אמין.

    כלומר, הייתה מצפה לראות את הביצוע של פקודות הטריגר מכוון שפקודת ה- Insert הצליחה, לא?

    וע"מ לשמור על אמינות המידה ה"מנוע" עוטף את פקודת ה- Insert וה-טריגר בטרנזקציה אחת.

    לאחר הנפילה הוא מאחזר את הנתונים של כל הטרנזקציות שעברו Commit אך עדין לא נרשמו ב- Data Files מה- Transaction Log ומכוון שפקודת ה- Insert לא עברה Commit עקב הנפילה בזמן הרצת הטריגר אתה תקבל, בזמן עליית המערכת, את המידה בצורה האמינה ביותר.

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

    היתה פותח את טבלה Y רואה את הערך 1 ובטבלה X לא הייתה מוצא נתונים ): ... הרבה יותר גרוע מנפילה של ה- Insert.

     

     

    מקווה שגם זה ברור ...

     

      


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 09:01
  • הסבר יפה של אסף...
    אני רוצ להוסיף נקודה לגבי ה "אז די מאכזב" ודוגמה להמחיש זאת

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

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

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

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

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


    • נערך על-ידי pituachMVP, Editor יום שלישי 13 ספטמבר 2011 09:37
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 09:15
    מנחה דיון
  •  קודם כל תודה רבה על התגובות המהירות והטובות - אבל קחו את המצב הבא ותגידו לי מה דעתכם:

    אני מפעיל טריגר על  הכנסת רשומה חדשה  לטבלה - לאחר הכנסת אני שולף מטבלת inserted   את הרשומה

    החדשה שנכנסה  בתוך הטריגר ומכניס את הרשומה לטבלה אחרת שקיימת במסד הנתונים וטבלה האחרת   ונפלתי על primary key

    אז אתם אומרים  שאם ה  insert   שבעקבותיו הופעל הטריגר צריך גם להתבטל.... מה זה לא הזוי קצת??

    שרון

     

    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 10:22
  • אהלן גיבור,

    אני מניח שאתה מכניס את הרשומה שנכנסה לטבלה אחרת לצורך Audits או כבסיס לפעולה אחרת.

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

    זה סנריו הרבה יותר גרוע !!!

    לדוגמא:

    רשומה חדשה, או עדכון רשומה, בטבלת לקוחות מכניסה לטבלת Client_Audits ע"י טריגר.

    טבלת Client_audits מהווה בסיס לטרנספורמציית הלקוחות ל- DWH.

    נפילה של הטריגר תייצר מצב שבו יש לי לקוח פעיל במקור שלא יהיה מוכר ב- DWH.

    לא נעים ואף יכול לגרום לבעיות רבות עקב בעיית Data integrity קשה.   

    בסה"כ מהנפילה למדתה:

    1. שיש לך בעיה בטבלת ה- "Audits", מניח שתיקנתה בקלות.

    2. שטריגר מוכל בתוך הטרנזקציה של המשפט שהפעיל אותו.

    3. את ההיגיון מאחורי הנושא.

    מזל שיש לפעמים תקלות :)

    יום טוב 


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 10:38
  •  אסף תודה

    אני מעכל את כל העניין :)

    יום שלישי 13 ספטמבר 2011 12:39
  • הי,

    ועכשיו לגבי, Try Catch.

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

    Create table dbo.Clients
    (
    	clId	int not null identity(1,1),
    	clCode	int not null,
    	clName	varchar(100)	
    )
    Go
    
    Create table dbo.Client_Audits
    (
    	claId				int not null identity(1,1),
    	-- The primary key will raise an eror if the same client will be inserted more than once
    	claClientCode		int not null Constraint PK_Client_Audits_claClientCode Primary Key, 
    	-- 
    	claName				varchar(100) not null,
    	claChangeDateTime	datetime not null	
    )
    Go
    
    Create trigger dbo.trg_a_i_Clients
    On dbo.clients
    for insert
    As
    	Insert  dbo.Client_Audits (claClientCode, claName, claChangeDateTime)
    	Select clCode, clName, GETDATE()
    	from inserted  
    
    Go
    
    Create procedure dbo.usp_Clients_Insert
    	@ClientCode int,
    	@ClientName varchar(100)
    As
    Begin
    	Insert dbo.Clients (clCode, clName)
    	Select @ClientCode, @ClientName
    End
    
    Go 
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    Select * from dbo.Clients 
    Select * from dbo.Client_Audits  
    
    -- Let Add the same client and see the resulsts
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    Select * from dbo.Clients 
    Select * from dbo.Client_Audits  
    
    /*
    	The duplicate insert did not affected the clients table, since there is no unique constraint on the clCode column
    	but did affect the  Client_Audits table that has a constraint, PK, and that rolled back the "internal" transaction
    */
    
    -- Lets try to avoid the scenarion with try\ catch blocks
    Alter trigger dbo.trg_a_i_Clients
    On dbo.clients
    for insert
    As
    Begin try	
    	Insert  dbo.Client_Audits (claClientCode, claName, claChangeDateTime)
    	Select clCode, clName, GETDATE()
    	from inserted  
    End Try
    Begin Catch
    	Print 'Error Occured' 
    End Catch
    Go
    
    exec dbo.usp_Clients_Insert 1, 'Assaf Shalem'
    
    /*
    	Has you can see in the result, the error did catched and handeled in the catch block; but the batch
    	has been aborted and the internal transaction has been rolled back.    
    */ 
    
    
    
    
    
    
    
    
    
    
    
    
    
    

     


    אסף שלם
    • סומן כתשובה על-ידי sharonof יום חמישי 15 ספטמבר 2011 14:10
    יום שלישי 13 ספטמבר 2011 15:03
  • היי,

    אשמח אם תוכל/י לעדכן אותנו בסטטוס השאלה שלך.

     

    במידה וקיבלת תשובה מתאימה לשאלתך, יש לסמן את התשובה המתאימה ע"י לחיצה על "סמן כתשובה" ליד סימון ה V הירוק

    אם לא קיבלת תשובה, מומלץ לספק פרטים נוספים אודות הבעיה, פרטי לוג, צילומי מסך וכו'

    על מנת להעלות תמונה לפורום ניתן להעזר במדריך להעלאת תמונה.


    אם תגובתי פתרה את בעייתך - לחץ/י, על "סמן כתשובה" ליד סימן ה V הירוק.

    על מנת להעלות תמונה לפורום ניתן להעזר במדריך להעלאת תמונה
    מיקרוסופט מציעה שירות זה ללא תשלום, למטרת סיוע למשתמשים והעשרת הידע הקשור בטכנולוגיות ובמוצרים של Microsoft. תוכן זה מתפרסם כפי שהוא והוא אינו מעיד על כל אחריות מצד מיקרוסופט.
    יום חמישי 15 ספטמבר 2011 13:01