Преглед:
Дебагирање е тешко кога развивање на сопствени функционалност за Windows SharePoint Services 3.0 (WSS) или Microsoft Office SharePoint Server (Мос). 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 кошница.
The "12 hive" is usually located at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12". (Не сум сигурен дали тоа е можно за 12 кошница да живеат на друго место, всушност).
Идејата е да се лоцираат на тековниот лог датотека, 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 кошница логови.
- Сортирање цел да се покаже со пат е изменета датум (најновите прво).
- Нагласи најактуелните log датотеката.
- Во веб прелистувач прозорец, сила на грешка да се случи.
- Брзо отворање на тековниот лог датотека и копирање на нивната содржина на MS Excel.
- Префрли се на крајот и анализираат релевантните записи.
Други белешки:
Од стандардните, дијагностички најавите се наоѓа во 12 кошница Дневници директориум.
MS Најдобри практики (кец на десетка од Мајк Т. на 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 кошница локација).
Овој запис прашањата како што се:
- SharePoint работното успеа да започне поради внатрешна грешка.
- (повеќе да се додаде со текот на времето)
- Забелешка: Оваа страница е корисно дијагностицирање на работното грешки (e.g. "The workflow failed to start due to an internal error").
Така, постојат моменти кога ќе појдам на 12 кошница логови и да се најде таму е малку да нема ништо во нив, иако влезете нивоа се такви што таму треба да биде податоци има. На пример, Седам тука гледањето на Windows Explorer поглед на логови папка и гледам дека, во просек, на логови се 1-2 Свирката. Но тогаш гледам неколку часа во кои логови се 10k. Сега, на SharePoint сајтови во прашање се во употреба доста 24 часа на ден. Па нешто се случува со теми / процеси генерирање на информациите кои ги спречуваат да влезете информации, Ќе морам да се претпостави. Така, како можам да дознаам што е што предизвикува ова прашање?
Дознав сето ова, кога отидов да одат на логови за да се обиде и debug проблем. Корисникот додаде дека веб дел и на веб дел им кажува да се провери логови. Но, се разбира, таму не е ништо во дневникот.
да ми помогне со грешка: LOG проект 5566