問:從別處複製乙個資料庫db，附加後，物件的所有者不是admini，每次查詢時必需寫select * from admini.***才能查到。用什麼方法不用前面的admini嗎（在不修改所有者的前提下）？
注：（已經在「安全性-登陸」下面也新建了乙個admini使用者，預設資料庫設定為db，許可權足夠，但在查詢分析器下用admini登陸，查詢時還是要寫admini字首，否則就提示物件名無效）
答：如果是用的是sql 2000的話，用某個使用者登入, 不指定所有者的話, 訪問物件的時候, 預設的所有者就是當前登入使用者
如果是2005的話, 在資料的安全性--使用者--右鍵你的使用者admin--屬性, 看看預設構架是什麼, 這個預設架構決定當你訪問物件時, 不指定所有者的話, 使用那個所有者(sql 2005中, owner變成構架了)
下面介紹一下會導致與上面的說法不匹配的異常情況：
如果在資料庫db中，admini是孤立使用者的話，則情況會與上面描述的有出入（附加或者恢復資料庫很容易出現孤立使用者），即引用物件時必須指定所有者。孤立使用者的表現是：只能建立admini登入, 並通過伺服器角色給其分配對db的許可權，或者是在db中建立名稱不是admini的使用者與登入關聯。
要查詢db中的孤立使用者情況，執行下面的語句：
use db go exec sp_change_users_login 'report'
解決孤立使用者的方法：
解決這種異常只要解決掉孤立使用者，在確定了admini是孤立使用者後，可以執行下面的語句來解決：
use db go -- 修復孤立使用者 exec sp_change_users_login 'auto_fix', 'admin', null, '密碼'; -- 這個密碼是指, 如果沒有事先建立admin 這個登入的話, sql自動建立登入時, 為該登入分配的密碼 -- 授予在db 中的相關許可權 exec sp_addrolemember 'db_
owner', 'admin'
C 箴言 必須返回物件時別返回引用
一旦程式設計師抓住物件傳值的效率隱憂，很多人就會成為狂熱的聖戰分子，誓要 傳值的罪惡，無論它隱藏多深。他們不屈不撓地追求傳引用的純度，但他們全都犯了乙個致命的錯誤 他們開始傳遞並不存在的物件的引用。這可不是什麼好事。考慮乙個代表有理數的類，包含乙個將兩個有理數相乘的函式 class rational...
條款21 必須返回物件時，別妄想返回其引用
條款21 必須返回物件時，別妄想返回其引用 includeusing namespace std class rational private int n,d friend const rational operator const rational lhs,const rational rhs c...
實施CMMI時必須解決的認識問題
在基於 cmmi 實施軟體過程改善時，有些根本的思想認識問題解決不了，往往會使實施的週期比較長，效果不好，甚至導致過程改善的失敗或中止。軟體企業的高層領導 企業的過程改進主管 專案經理及一般的開發人員都需要對這些問題統一認識，在此基礎上才能消除各方面的阻力，把握好過程改善的方向，控制好過程改善的進度...