每月檔案: 2 月 2008

周日滑稽: “不適用於出口”

發表評論

繞回來 1998, 我當時工作的公司收到了一些資金，以創建一個新的電子商務產品. 我們有各種各樣的業務需求來滿足. 它必須是快速, 為最終使用者提供方便, 奢華, 多語言, 等. 不幸的是, 大概沒了作為一套宏偉的那些令人興奮的日子以來完成的工作.

這一努力預日構架. 普通的香草 ASP 仍然是有些新 (或至少對我的公司很不熟悉). "磚和砂漿" 公司是註定. 註定要! 這是說它開創性工作. 不強子對撞機開拓性的工作, 但是，我們在我們的小世界, 它開拓性工作.

我們瘋了忙. 我們在做迷你 POC 的幾乎每一天, 找出如何在本質上無國籍的介質中維護狀態, 搞清楚多語言問題, 行級安全性. 我們甚至已經創建的詞彙來定義基本術語 (我首選狀態持久性，但出於某種原因, 尷尬的"statefull" 贏得這一天).

正如我們在瘋狂地創造此產品, 在那兒試圖賣掉它，行銷和銷售人. 不知何故, 他們設法把它賣給我們噩夢般的場景. 即使我們被設計和實施企業解決方案, 我們真的沒想到的第一個客戶要使用我們的產品一天零建成每一功能. 這位客戶需要多語言, 從"標準從根本上不同的使用者介面" 系統使用相同的業務邏輯，但. 多語言在這種情況下，尤其是硬, 因為我們始終專注于西班牙文或法文, 但在此情況下, 這是中國 (這是一個雙位元組字元設置和所需特殊處理給我們使用的技術).

我和幾個月飛快地向前吧到北京的西北航空班機. 我一直忙著準備這次旅行，我幾乎不知道去那裡是什麼. 我讀過一本書一次關於如何美國幾年來在中國一直和掌握了語言. 一天他走城市和一些人問路. 去談話的東西這:

  • 美國: "你能告訴我怎麼去 [XX] 街?"
  • 中文: "抱歉, 我們不會說英語".
  • 美國: "哦, 好我說普通話。" 他再問他們在中國, 但更清楚 (他所能最好).
  • 中文: 很有禮貌地, "抱歉, 我們不會說英語".

談了這樣一點，美國放棄了在挫折中. 當他離開他們，他無意中聽到說話，另一個人, "我敢發誓，他在問路到 [XX] 街。"

我接了幾個雙邊投資條約和其他與中國相關的准資訊和"有用的建議"的片斷:

  • 參與合作韓國告訴我我需要要小心中國人的因為"他們將會嘗試把我灌醉並利用你" 在向我施加壓力到不好的業務決策的感覺.
  • 我們不允許開汽車 (有一些混亂，這是否是一個自訂, 法律要求或只是用戶端的規則).
  • 有會通過海關的特殊規則.
  • 我們不是允許使用美國的金錢的東西.
  • 你不應該離開小貼士. 它是侮辱性的如果你這樣做.

最後, 我有相對新鮮的記憶 天安門大屠殺. 當時大學, 我記得我看到即時的 Usenet 帖子作為在驚恐中的世界.

在短, 當時我很緊張. 我並不只是正常緊張的意義上說，我送了數量級比任何東西都更複雜我之前做過的解決方案. 我也是擔心不小心打破一個規則，可以給我麻煩.

我在這 14 小時的飛行，儘管它是業務類, 14 小時是該死長一段時間. 有只很多方式來娛樂自己通過閱讀, 看電影或玩磁化餐具. 即使真正的好書很難讀幾個小時直.

最終, 我開始閱讀一種軟體我用手提著和我一起到用戶端上的包裝材料, 網景公司的 web 伺服器. 我正在讀的硬體/軟體要求, 市場行銷導語, 突然看著漂亮的圖片, 我零上的巨人"不適用於出口" 警告, 有關的東西 128 位加密. 我把盒子塞回我隨身攜帶的包, 警告面朝下 (如果那會有説明) 試圖保持的幻象 午夜快車 從我的頭.

回過頭來看現在, 應一直擔心, 如果在所有, 當我離開美國, 不是在我進入中國的時候 🙂 沒有發生任何不愉快的事情，我仍然認為這是我有幸進行的最好、最難忘的商務旅行.

</結束>

訂閱我的博客!

Technorati 標籤: ,

解決方案: SPQuery 不能搜尋資料夾

3 回复

過去這周我正在實施"演變" 使用 BDC 和 SPQuery 並遇到一些困難，使用 SPQuery 針對包含資料夾的文件庫的用戶端解決方案. 底線: 分配"遞迴" 在視圖屬性中的查詢.

我的方案:

  • 週一, 上傳文檔，並提供一些中繼資料.
  • 下一周, 我上傳一個新的文檔. 很多此新文檔的中繼資料基於我週一傳的文檔 (我們稱之為"主控文件").
  • 我們已經創建了 web 服務的屏風，這提供一個 BDC 友好介面到清單中，以便使用者可以方便地找到那個星期一文檔通過標題搜索.
  • BDC 資料列提供了一個友好的使用者介面. (這是嘗試的我在為一個更友好的查閱列使用 BDC 的一部分).

最後的 BDC 外立面服務使用像這樣的查詢進行查找:

 // U2U 工具用於説明生成此 CAML 查詢.
      oQuery.Query =
        "<在哪裡>";

      如果 (titleFilter.Length > 0)
        oQuery.Query   =
          "  <和>";

      oQuery.Query   =
        "    <和>" +
        "      <Geq>" +
        "        <FieldRef 名稱 = "DocumentId" />" +
        "        <數值型別 = "Text">" + minId + "</價值>" +
        "      </Geq>" +
        "      <Leq>" +
        "        <FieldRef 名稱 = "DocumentId" />" +
        "        <數值型別 = "Text">" + maxId + "</價值>" +
        "      </Leq>" +
        "    </和>";

      如果 (titleFilter.Length > 0)
        oQuery.Query   =
          "    <包含>" +
          "      <FieldRef 名稱 = "Title" />" +
          "      <數值型別 = "Text">" + titleFilter + "</價值>" +
          "    </包含>" +
          "  </和>";
      oQuery.Query   =
        "</在哪裡>";

在發展的初始階段, 這工作得非常棒. 不過, 我們引入的目錄來解決一些問題的資料夾和突然, 我 BDC 選取器不會返回任何結果. 我跟蹤這 SPQuery 將永遠不會返回任何結果的事實. 我們資料夾主要用於允許多個檔具有相同的名稱，要上載，但使用不同的中繼資料. 當上載檔, 我們創建一個基於 ID 的清單項的資料夾，然後將該檔移那裡 (我曾寫過， 在這裡; 我們已經 好壞參半的結果 這種方法，但總體上, 它工作好). 使用者不關心資料夾，事實上, 真不明白有任何資料夾. 我們已經配置上要顯示的專案而不考慮資料夾的庫的所有視圖.

我打了兩倍的技術實施發展和解決它以不同的方式每次這個問題. 第一次, 我不在查詢中使用包含運算子. 沒有包含運算子, 我是能夠解決的問題通過指定視圖上 SPQuery 的建構函式. 而不是使用預設的建構函式:

SPList oList = web。清單["檔"];

SPQuery oQuery = 新增功能 SPQuery();

我轉而用於指定視圖的建構函式:

SPList oList = web。清單["檔"];

SPQuery oQuery = 新增功能 SPQuery(oList.Views["所有文檔"]);

這解決了這個問題，我開始變得我的結果.

然後加入混合的 CONTAINS 操作符，它再一次打破了. 原來，包含運算子, 到目前為止，我可以告訴, 不能與視圖相同的方式更簡單的 GEQ / LEQ 運算子. 我做了一些搜索，學到了，該查詢 ViewAttributes 應該設置為"遞迴", 如在:

oQuery.ViewAttributes = "範圍 = "Recursive"";

包含用於解決了這個問題. 事實上, 這也解決了我原來的搜索問題，如果我有指定遞迴屬性第一次, 我將不會遇到這一問題再一次.

基於視圖的 SPQuery 工程部分經營者這一事實 (GEQ/LEQ) 而不是別人 (包含), 加上這一事實似乎 Kpi 不能工作在所有與此資料夾包含的文件庫主角我相信 SPQuery 具有正交性的幾個問題.

特別感謝:

  • 在的好人們 U2U 和他們的查詢工具.
  • 邁克爾 · 哈弗的偉大 "邊學邊做" 博客張貼內容, 意見及回應.

</結束>

訂閱我的博客!

MOSS KPI 的 bug? 綁定到文件庫的資料夾的清單指示器

1 答覆

更新 02/29/08: 這解決了創建一個資料夾，然後將內容類型分配給有需要用於 Kpi 的 meta 資料的資料夾. 中一些更多的細節所述，.

我們已實施技術解決方案，使用者將文檔上載到文件庫. 事件接收器創建目錄，並將檔移到該目錄 (使用與我曾寫過類似的技術 在這裡). 我們已經成功地駛過致重命名上傳的檔的事件接收器的潛在問題 (主要是因為使用者永遠不會通過點擊"新建開始他們的文檔" 但相反創建本地的文檔，然後將它們上載).

這些檔的中繼資料包括 Yes/沒有網站列稱為"緊急" 和另一個網站欄名為"狀態". 我們需要顯示的百分比"緊急的業務要求" 其狀態為"掛起"的文檔.

這是通常簡單做 和我描述很多這樣的事在 SharePoint 獵兔犬 有很多的螢幕截圖，如果你有興趣.

總括, 我做了以下:

  • 創建一個稱為"掛起"的文件庫的視圖.
  • 配置要忽略的資料夾結構的視圖.
  • 創建 KPI 清單.
  • 創建指向文件庫和清單中的一項指標"掛起" 視圖.

這是完全行不通. KPI 顯示我的目標 (例如：. 五個緊急檔) 但總是顯示緊急檔為零的實際數. 矛盾的是, 如果您深入查看詳細資訊, 它顯示清單中的五個緊急檔. 我與兩個文檔創建一個非常簡單的場景, 一個在一個資料夾和一個不. 這裡是螢幕截圖:

圖像

上面的螢幕擷取畫面清楚顯示有兩個文檔中的視圖，但"價值" 是一種. "CamlSchema" 空白文檔 Id 是根資料夾中，另一個是在一個名為"84"資料夾中.

在我看來，即使您指定的視圖, KPI 不會榮譽"顯示所有專案沒有資料夾" 設置，而, 限定自己到根資料夾.

如果我錯了, 請放我一條線或留下評論.

</結束>

訂閱我的博客!

Technorati 標籤:

展能就業科的工作流 “從使用者收集資料”: 修改生成的工作表單

4 回复

我正在進行一個專案，使用五個不同 SharePoint 設計師工作流來處理一些文檔審批. SPD 提供從使用者的"收集資料" 行動以便我們可以提示使用者輸入資訊的不同位, 例如，是否他們批准它, 一些評論，也許問他們了前幾天的晚餐.

形式是完美的功能. 他們都向工作清單作為內容類型. 他們是 100% 系統生成. 這是他們的力量和弱點. 如果我們能活著與預設表單, 然後我們就去. 不過, 我們不能太多控制 SPD 如何創建表單. 如果我們不喜歡這種預設行為, 我們需要求助於各種伎倆來繞過它 (舉個例子, 為任務設定優先權).

在這些工作表單上開闢了視圖屬性提供一個連結所需 (dispform.asxp) "相關專案的" 在新視窗中. 這提供了一鍵式訪問到相關專案的中繼資料. 這是我的意思是:

圖像

值得慶倖的是, 我們可以這樣做並不是很難. 概括地說, 點燃電湧保護器, 導航到房子的工作流檔的目錄，然後打開您想要修改的 ASPX 檔. 這些都只是經典的 XSL 變換指令，如果你已經弄亂 itemstyle.xsl, 搜索或其他 XSL 方案, 這將便於您. 事實上, 我發現這是通常更容易，因為生成的表單是一定程度上容易遵循與搜索核心結果 web 部件 (或 夢魘般的 CWQP).

答案是肯定的, 還有一個主要的陷阱. SPD 的工作流編輯器預計該檔的完全控制權. 如果你對其進行修改, SPD 將愉快地覆蓋權設置的情況下你的變化給. 我做兩個快速測試，看看這能得到多麼糟糕. 他們都預先假定你已經精心設計有效的 SPD 工作流使用來自使用者的"收集資料" 一步.

測試 1:

  • 用手修改 ASPX 檔.
  • 對它進行測試 (驗證您的更改被正確的保存，並沒有破壞任何東西).
  • 開放工作流，並添加一個不相關的操作 (如"到歷史記錄日誌").
  • 保存工作流.

結果: 在此情況下, 展能就業科並不重新創建表單.

測試 2:

  • 做相同 #1 除了直接修改的"收集資料從使用者" 行動.

結果: 這將重新創建表單從零開始, 修改您的更改.

最後說明:

  • 至少兩個電湧保護器操作創建表單像這樣: "從使用者收集資料" 和"分配做專案". 這兩種操作’ 可以手動修改表單.
  • 我是能夠生成我連結到 dispform.aspx，因為, 在這種情況下, 相關專案總是有相關的專案 URL 中嵌入其 ID. 我是能夠提取它，然後再生成 <a href> 在此基礎提供一次按一下中繼資料訪問功能. 它不太可能您的 URL 遵循這個規律. 可能有其他方法可以獲得相關的項的 ID，但還沒有過那座橋, 所以我不知道如果獲取到另一邊的鴻溝.
  • 我才調查, 但我不會感到驚訝，如果有某種類型的範本檔中 12 可以修改影響 SPD 將預設表單的生成的配置單元 (就像我們可以修改通知範本).

</結束>

訂閱我的博客!

Technorati 標籤: ,

正在 “未知的錯誤” 消息真的比一個堆疊追蹤?

3 回复

我在閱讀如何 Madhur 的博客 啟用堆疊追蹤顯示 現在我想知道: 為什麼不要我們總是顯示堆疊追蹤?

誰走過來與該規則，為什麼我們要遵循它?

最終使用者會知道無論哪種情況不對勁. 至少與一個堆疊追蹤, 他們可以按控制列印螢幕, 複製/粘貼到電子郵件並將它發送給它. 這顯然會減少解決問題所需的精力與時間.

</結束>

Technorati 標籤:

星期日 (令人尷尬) 搞笑: “我的名字是保羅 · 高爾文”

1 答覆

幾年前一群, 我的老闆問我要一些使用者進行一種叫做結果產品培訓. 結果是最終使用者報告工具. 它是大致類似于 SQL 伺服器報表服務或水晶. 在時間, 它旨在在綠色管上運行 (例如：. Wyse 50 終端) 連接到 Unix 盒通過 telnet.

我的預設回答開頭的任何問題"你能 … " "是" 這就是所有麻煩的都開始.

在用戶端是出在南加州一家化學公司和只是約裹了起來基於主要 ERP 實施 QAD 的 MFG/PRO. 實施計畫現在呼籲為培訓力量最終使用者結果產品.

我不是此工具的大使用者，當然從未鍛煉之前的任何人. 不過, 我進行了幾次其他培訓類的是快速的在我的腳上, 所以我並不太擔心，. 鄧尼斯 ·, 真正全職結果講師, 給了我他的培訓材料. 回過頭來看現在, 這種真的很荒謬. 我不了解的產品, 從來沒有正式對它訓練和當然從來沒有告訴它. 訓練它的任何人都有什麼業務?

後勤上複雜的東西, 我應邀去了，遇見一個人在芝加哥作為預銷售接洽沿途的一部分. 計畫是要飛出新澤西, 去芝加哥, 一個小時會晤前景，然後繼續飛往加利福尼亞.

井, 我到芝加哥和我的團隊銷售的傢伙犯了一些錯誤，從未證實會議. 所以, 我出現了，前景不在那裡. 令人敬畏. 我收拾好，離開繼續 CA. 在此過程中的某個地方, 我找出用戶端學習少於 24 之前我的到來，"Paul 高爾文小時" 教學班, 不是鄧尼斯. 用戶端愛鄧尼斯. 他們想要知道"是這個 Paul 高爾文人?" "為什麼我們應該相信他?" "為什麼我們應該為他?" 鄧尼斯顯然不是贊同我 "早給壞消息" 哲學. 令人敬畏.

我到達機場的和一些令人難以置信的愚蠢的原因, 我已經檢查我的行李. 向 LAX 但我的行李卻沒有. 對我來說, 丟失的行李很多就像經歷 悲傷的七個階段. 最終我能去酒店, 與沒有行李, 累了, 餓了，戴著我 (現在, 很皺巴巴) 西裝. 它需要很長的時間才能從紐華克 — 到奧黑爾 — 到用戶端 — 追溯到奧黑爾 — 最後在洛杉磯國際機場.

我終於發現自己坐在酒店房間裡, 士力架欄上大嚼, 搞得精疲力竭，試著鼓起的能量，通過培訓材料再次掃描，我不會看起來像十足的蠢驢，當著全班的面. 這是當時我的一個低點位.

我醒了，第二天, 我最大努力撫平我的西裝，看起來沒喜歡嗎威利 · 洛曼在糟糕的一天，奔到用戶端. 正如經常的情況, 在的人，她是很好, 有禮貌、 很愉快. 這對她非常生氣的電子郵件/語音信箱的前一天站在形成鮮明的對比. 她帶領我關於 3 通過對分段建築英里地區，在一個巨型的化工倉庫，在那裡我們會進行類接下來的三天. " 15 或 20 學生慢慢地組裝, 她們中的大多數仍然期待鄧尼斯.

我總是先關閉我的培訓課介紹我自己, 給一些背景和寫作我在白板上的聯繫資訊. 像我說的, "早上好, 我的名字叫 Paul 高爾文", 我寫我的名字, 電子郵件和電話號碼向上大的字母，這樣，每個人都可以清楚的看到它在白板上. 我處理的事實，我接替鄧尼斯，我向他們保證我是合適的替代, 等. 我讓每個人簡要地告訴我他們的名字和他們想要獲得在課下，我可以定制滿足其具體需求的東西，我走. 一些常用的東西.

我們包起來和火起來的投影儀. 我去抹去我的連絡人資訊和 … 我寫了在永久性標記. 所以窘. 在我的腦海, 它看起來就像這: 有這"保羅 · 高爾文" 人, 最後一分鐘更換為我們心愛的鄧尼斯的. 他穿著皺巴巴了西裝、 鬍子拉碴. 他只是在我們白板上寫他名字巨大的字母 永久標記. 多麼的景象!

一切都結束了快樂, 然而. 這是一家化學公司, 畢竟. 一位灰白頭髮資深員工拉從架子上的東西，, 大概是在違反環保法規, 清除審計委員會. 我設法保持 1/2 整個課程班前一天，他們給了我好好複習中結束. 這鞏固了我的"父愛" 在我公司的聲譽. 我的行李到達的第一天, 所以很多像樣天二和第三.

當我正在回家的紅色眼睛, 我苦苦思索"經驗教訓". 有很多可以考慮. 溝通是關鍵. 告訴客戶更改計畫中. 永遠不要檢查你的行李在機場如果你可能可以避免它. 帶備用"的東西" 萬一你做檢查你的行李和它不使它. 我認為最重要的教訓, 然而, 這是: 在左下角的白板在寫作之前，一定要測試一個標記, 在巨大的信件, "保羅 · 高爾文".

</結束>

Technorati 標籤: ,

觀點: SharePoint vs. 大型強子對撞機

發表評論

由於一些古怪聯合航空公司航班在 90 年代中期, 我不知怎麼實現最終要變換的"未使用的里程約" 到十幾個免費雜誌訂閱. 這就是我是如何結束美國科學雜誌訂閱.

作為軟體 / 諮詢人, 我們在我們的職業生涯中遇到很多困難的業務需求. 大部分時間, 我們愛滿足這些要求，事實上, 這可能是為什麼我們認為這個職業是世界上最好的. 我偶爾不知道只是世界上我如果會做與自己在歷史上的任何其他時候都生來. 將錯過我現在要做的工作的種類將會多麼可怕, 在這個時間和地點在世界歷史上? 我認為: 很可怕.

多年來, 我面對過的要求有一些極具挑戰性，滿足. 複雜的 SharePoint 東西, 建立 web 處理框架基於非 web 友好技術, 複雜的 BizTalk 業務流程等. 我們都能 (希望) 自豪地回頭看我們的職業生涯和說, "是的, 這是一個很難解決, 但最終我閉那狗娘養的!" 更重要的是, 甚至更有趣、 更好玩的挑戰等待.

我個人認為，我的簡歷, 在這方面, 是很深很自豪的它 (雖然我知道我的妻子不是會明白 1/20，它). 但在這周, 我讀到一篇關於 大型強子對撞機 在我美國科學雜誌和有一個那些罕見的羞辱我意識到我的巨人"儘管" 在某些圈子或多深，我覺得我很好的經驗中的地位, 在完全不同的世界裡有真正的偉人.

一些很棘手的問題，管理人對大型強子對撞機團隊. 考慮月亮. 我真的不認為許多關於月球的 (雖然我一直很懷疑，它因為我學到了地球的自轉的速度, 其中不能長遠來說是件好事對我們人類). 但, 大型強子對撞機團隊不必擔心. 大型強子對撞機的測量設備是如此敏感，他們受月亮的 (Earth-rotation-slowing-and-eventually-killing-all-life) 重力. 這是一件了不起的要求以滿足 — 產生正確測量儘管月球的干擾.

我思考這個問題，當我讀到這句話: "第一級將接收並分析中只有一個探測器的所有元件的子集的資料, 從它可以挑出基於孤立的因素，例如是否有前途事件，精力充沛的 μ 介子被發現在大角度從梁軸飛出來。" 真的 … ? 在這種的沙箱和永遠不會我不玩.

下一次我與一些朋友, 我要去敬在 LHC 上工作的很好的人, 希望他們不要成功地權衡希格斯玻色子粒子和詛咒月亮. 我建議你做相同. 這將是相當的祝酒 🙂

</結束>

Technorati 標籤:

快速的印象: SharePoint 系統中心容量規劃師

發表評論

我剛炒了容量規劃工具的 這些天的所有憤怒.

發現它便於使用，並快速建模工作今年夏天的用戶端環境.

有些惶恐, 我按下了最後的確定按鈕，它建議非常類似于我們給我們的客戶的東西 (我們實際上扔在第二個應用程式伺服器中為未來 excel 使用). 我認為這個是一個好兆頭，增加我的自信在工具中.

它看起來很強大的東西更多好的出發點比一個空白頁.

我喜歡那個讓你進入某些好的細節資訊環境. 有多少使用者, 你如何專案他們將使用系統 (發佈, 合作, 等), 分支辦公室和連通性 / 他們與媽媽伺服器之間的網路容量. 好的東西.

它先廣泛基於提出問題，然後允許您調整您的環境相當精細模型的詳細資訊.

我猶豫了一下下載它，因為我有很多其他事情要看著它, 閱讀並試圖消化. 我很高興我這麼做.

這是一個簡單的兩步過程. 下載系統中心容量規劃師，然後下載 SharePoint 模型. 它在 Windows XP 上運行的很好.

基於我快速的印象, 它可能會考慮如何看不到:

  • 搜索: 文檔總數, 也許類型的文檔, 語言.
  • Excel 伺服器: 多少, 如果在所有?
  • 表單伺服器: 多少, 如果在所有?
  • BDC: 多少, 如果在所有.

那些可能進行建模和我只是沒看到他們在 10 分鐘審查.

我一定會在我下一次用戶端使用它.

如果沒有 顧問 而是為一個真實公司工作 :), 我將模型我當前的環境，看看該工具的推薦的模型與現實的匹配. 那將是很整潔. 它可能會導致一些良好的基礎設施的討論.

</結束>

Technorati 標籤:

解決方案: 對 System.IO.FileNotFoundException “中的 SPSite = 新中的 SPSite(url)”

11 回复

更新: 我發佈這一問題到 MSDN 在這裡 (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) Michael Washam 的微軟用一個簡明的答案進行了回擊.

創建 web 服務，以作為 BDC 友好門面 到 SharePoint 清單. 當我用這個從我的開發環境, 它能正常工作. 當我這遷移到新的伺服器, 此錯誤:

System.IO.FileNotFoundException: 在 Web 應用程式 http://localhost/sandbox 無法找到. 驗證正確地鍵入 URL. 如果 URL 應該提供的現有內容, 系統管理員可能需要添加一個新的請求的 URL 對應到目標應用程式. 在 Microsoft.SharePoint.SPSite...建構函式(SPFarm 農場, Uri requestUri, 布林 coNtextSite, SPUserToken userToken) 在 Microsoft.SharePoint.SPSite...建構函式(字串 requestUrl) 在 Conchango.xyzzy.GetExistingDocument(字串 minId, 字串 maxId, 字串 titleFilter) C:\文檔和 SettingsPaulMy DocumentsVisual 工作室 2005ProjectsxyzzyBDC_DocReviewBDC_DocReviewDocReviewFacade.asmx.cs:線 69

這裡是線 69:

使用 (SPSite 網站 = 新 SPSite("http://localhost/sandbox"))

我試著 URL 不同變奏曲, 包括使用伺服器的真實姓名, 它的 IP 位址, 該 url 的斜線結尾, 等. 我總是得到該錯誤.

我用 在谷歌 它的研究. 很多人面臨著這個問題, 或它的變化, 但似乎沒有人出錢解決.

Tricksy MOSS 提供詳細它並沒有給我檢查發生的錯誤 12 蜂巢日誌. 最終, 關於 24 小時後 我的同事 推薦我這樣做，, 簽出狀態 12 配置單元日誌，發現這: 

嘗試獲取本地農場時出現異常:
System.Security.SecurityException: 不允許進行請求的註冊表訪問.
在 System.ThrowHelper.ThrowSecurityException(ExceptionResource 資源) 在 Microsoft.Win32.RegistryKey.OpenSubKey(字串名稱, 布林值可寫) 在 Microsoft.Win32.RegistryKey.OpenSubKey(字串名稱) 在 Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() 在 Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() 在 Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& 農場, 布林值& 種矛盾又摻雜)
失敗的程式集的區域是:  我的電腦

這開闢了新途徑的研究, 所以它又回到了谷歌. 我被引到這 論壇帖子: http://forums.codecharge.com/posts.php?post_id = 67135. 這真的幫不了我，但它確實開始讓我覺得那裡是一個資料庫和/或安全的問題. 我受盡折磨和 安德魯 · 康奈爾 最後觸發後說我要確保應用程式池標識帳戶有權訪問資料庫的思想. 我以為它已經打了. 不過, 我的同事去和給 SQL 應用程式池標識帳戶完全訪問.

為她做了這種變化, 一切都開始工作.

下面發生的事情是最好的表示為 俳句 詩:

問題舉手.
你擺動和小姐. 再試一次.
成功! 但如何? 為什麼?

她並不想這樣獨自一人離開的事情, 更傾向于給最低所需的許可權 (可能著眼寫博客條目; 毒打沖到, muhahahahaha!).

她從應用程式池標識帳戶之前刪除連續的許可權 … 已不再有任何明確權限的應用程式池標識帳戶在所有. Web 服務繼續工作得很好.

我們去和重新開機伺服器. 一切繼續做工精細.

所以, 重述一遍: 我們給應用程式池標識完全存取權限，然後把它拿走了. Web 服務開始工作，永遠不會停止工作. 奇怪.

如果有人知道為什麼應該會起作用, 請留下評論.

</結束>

Technorati 標籤: