მიმოხილვა:
დახვეწის ძნელია, როცა განვითარებად საბაჟო ფუნქციონალური for Windows SharePoint Services 3.0 (WSS) ან Microsoft Office SharePoint Server (Moss). The main culprit is that SharePoint normally surfaces very little diagnostic information on the web browser when an error occurs. This blog entry describes how to locate additional system-generated diagnostic information that can often provide that extra bit of detail that one needs in order to identify root causes. This can then lead to solving the problem.
მე არ გამოიყენება ამ ტექნიკის დიდი წარმატებით მოსაგვარებლად სხვაგვარად საიდუმლოებით მოცული შეცდომები.
მიდგომა:
SharePoint ნახტომი დიდი ინფორმაციის სადიაგნოსტიკო შესვლა ჟურნალი ფაილი 12 hive.
The "12 hive" is usually located at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12". (მე არ ვარ დარწმუნებული, თუ ეს შესაძლებელია 12 hive იცხოვროს სხვაგან, სინამდვილეში).
იდეა იქნებიან მიმდინარე ჟურნალის ფაილი, force the error and then quickly open the log file. These log files are characterized by:
- Copious amounts of information. SharePoint generates a very large amount of diagnostic information and writes it to that log file very quickly. You need to be quick with the fingers to capture it.
- Multiplicity. SharePoint does not write to a single log file but rather generates multiple log files in sequence.
- დააკოპირეთ ლამაზად შევიდა MS Excel.
ჩემი საყვარელი მეთოდი:
- ქმნის Windows Explorer მიუთითებს 12 hive მორების.
- Sort რათა ნახოთ მიერ განახლდა თარიღი (უახლესი პირველი).
- მონიშნეთ უახლესი ჟურნალი ფაილი.
- In ბრაუზერში ფანჯარა, აიძულოს შეცდომა უნდა მოხდეს.
- სწრაფად გახსნა მიმდინარე ჟურნალის ფაილის და დააკოპირეთ მისი შინაარსი, რომ MS Excel.
- გადახტომა ბოლოს და ანალიზი შესაბამისი მასალა.
სხვა შენიშვნები:
სტანდარტულად, სადიაგნოსტიკო ჟურნალი მდებარეობს 12 hive ლოგები დირექტორია,.
MS საუკეთესო პრაქტიკა (როგორც პოსტი მაიკ T. Microsoft-) state that the log files should be saved to a separate hard drive. One does this via central admin. Your system administrator may have done this, ამ შემთხვევაში ნეტავ აშკარად გვჭირდება, log ფაილი არსებობს ნაცვლად სტანდარტული 12 hive მდებარეობა).
ამ ჩანაწერში მიმართავს ისეთ საკითხებზე, როგორიცაა:
- SharePoint workflow ვერ განხორციელდა იმის გამო, რომ შიდა შეცდომა.
- (მეტი დაემატოს დროთა)
- ამ ჩანაწერში უკვე გამოსადეგი დიაგნოზის workflow შეცდომები (e.g. "The workflow failed to start due to an internal error").
ასე რომ,, არის დრო, როცა მივდივარ 12 hive ჟურნალი და იპოვოს არის პატარა არაფერია მათში, მიუხედავად იმისა, რომ ხე დონეზე ისეთი რომ უნდა იყოს მონაცემებით. მაგალითად, მე სხდომაზე აქ ეძებს Windows Explorer ხედი მორების საქაღალდეში და ვხედავ, რომ, საშუალოდ, მორების არიან 1-2 კონცერტი. მაგრამ მე ვერ ვხედავ რამდენიმე საათი რომელიც მორების არიან 10k. ახლა, SharePoint საიტები კითხვაზე გამოიყენება საკმაოდ ბევრი 24 სთ დღეში. ასე რომ რაღაც ხდება თემა / პროცესებში მომტანი ინფორმაცია, რომ თავიდან იქნას აცილებული მათ ხე ინფორმაცია, მე უნდა ვივარაუდოთ,. ასე რომ,, როგორ უნდა გაერკვნენ, თუ რა იწვევს ამ საკითხის?
აღმოვაჩინე ეს ყველაფერი, როდესაც მივედი წასვლა მორების ცდილობენ და გამართვის პრობლემა. მომხმარებლის დასძინა ვებ ნაწილი და ვებ ნაწილი ეუბნება მათ შეამოწმოს მორების. მაგრამ, რა თქმა, იქ არაფერი ჟურნალი.
დაეხმაროს ჩემთვის შეცდომა: შესვლა ID 5566