Time of Update: 2017-01-19
在Transact-SQL語句中,我們主要使用OpenDataSource函數、OPENROWSET 函數,關於函數的詳細說明,請參考SQL線上說明。利用下述方法,可以十分容易地實現SQL SERVER、ACCESS、EXCEL資料轉換,詳細說明如下: 一、SQL SERVER 和ACCESS的資料匯入匯出 常規的資料匯入匯出: 使用DTS嚮導遷移你的Access資料到SQL Server,你可以使用這些步驟: 1在SQL SERVER企業管理器中的Tools(工具)菜單上,選擇Data
Time of Update: 2017-01-19
1、確認資料庫服務開啟狀態 2、php.ini配置中的擴充開啟 3、檢查資料庫相關的版本 (1)Sql2000此時要檢查php目錄和apache的bin目錄下的ntwdblib.dll檔案的版本是否符合,右鍵點擊ntwdblib.dll看檔案屬性就可以看見版本。Sql2000對應的ntwdblib.dll應該是7.0的版本 (2)Sql2005的時候ntwdblib.dll對應的是8.0的版本。 如果版本不對可能出現連結失敗,仔細檢查即可。
Time of Update: 2017-01-19
大部分人都知道用oledb來讀取資料到dataset,但是讀取之後怎麼處理dataset就千奇百怪了。很多人通過迴圈來拼接sql,這樣做不但容易出錯而且效率低下,System.Data.SqlClient.SqlBulkCopy 對於新手來說還是比較陌生的,這個就是傳說中效率極高的bcp,6萬多資料從excel匯入到sql只需要4.5秒。using System; using System.Data; using System.Windows.Forms; using
Time of Update: 2017-01-19
Display SQL Server Version Information Description Display SQL Server Version Information. Supported Platforms SQL Server 2000 Yes Script Code strDBServerName = "." Set
Time of Update: 2017-01-19
Display SQL Server Login Mode. Supported Platforms SQL Server 2000 Yes Script Code SQLDMOSecurity_Integrated = 1 SQLDMOSecurity_Mixed &
Time of Update: 2017-01-19
Sample script that displays all of the users in a given SQL Server DB. Supported Platforms SQL Server 2000 Yes Script Code 複製代碼
Time of Update: 2017-01-19
Create a SQL Server database.複製代碼 代碼如下:DB_SIZE_IN_MEGABYTES = 5 strDBServerName = "." Set objSQLServer = CreateObject("SQLDMO.SQLServer") objSQLServer.LoginSecure = True
Time of Update: 2017-01-19
簡介資料庫快照集 資料庫快照集,正如其名稱所示那樣,是資料庫在某一時間點的視圖。是SQL Server在2005之後的版本引入的特性。快照的應用情境比較多,但快照設計最開始的目的是為了報表格服務。比如我需要出2011的資產負債表,這需要資料保持在2011年12月31日零點時的狀態,則利用快照可以實現這一點。快照還可以和鏡像結合來達到讀寫分離的目的。下面我們來看什麼是快照。什麼是快照 資料庫快照集是
Time of Update: 2017-01-19
本系列文章一直所沒有觸及的就是有關”還原(Restore)”的話題,因為一旦牽扯到這個話題就會涉及大量的誤區,多到我無法通過一篇文章說完的地步。事實上,我希望用字母表的順序為每一個誤區進行編號,希望你看了不要昏昏欲睡。下面開始揭穿這26個誤區。誤區 #24: 26個有關還原(Restore)的誤區都是錯誤的24 a)可以通過WITH
Time of Update: 2017-01-19
誤區 #23: 鎖定擴大的過程是由行鎖定擴大到頁鎖,再由頁鎖定擴大到表鎖錯誤 實際不是,在SQL Server 2005和之前的版本,頁鎖會直接升級到表鎖。 在SQL Server 2005或SQL Server
Time of Update: 2017-01-19
誤區 #22: 資源管理員可以調控IO錯誤 資源管理員無法調控IO,希望下一個版本的SQL Server支援調控IO,調控IO對於對於減少對於大表的scan操作帶來的效能影響很有協助。 下面列表中的功能資源管理員同樣也無法完成:調控Buffer Pool的記憶體,記憶體調控器僅僅可以調控執行計畫所佔的記憶體,但對於Buffer
Time of Update: 2017-01-19
誤區 #20:在破壞記錄備份鏈之後,需要一個完整備份來重新開始日誌鏈 錯誤 交易記錄備份會備份自前次交易記錄備份以來所有的交易記錄(如果從來沒有過記錄備份的話,那就從上一次完整備份開始)。有好幾種類型的操作會中斷交易記錄的連續性,也就是說除非重新開始新的日誌鏈,SQL Server無法再進行記錄備份。下面這幾種操作都有可能引起日誌鏈斷裂: 由完整復原模式或大容量交易記錄復原模式轉為簡單復原模式 從資料庫鏡像進行恢複 備份日誌時指定了NO_LOG 或 WITH
Time of Update: 2017-01-19
誤區 #19:Truncate表的操作不會被記錄到日誌 錯誤 在使用者表中的操作都會被記錄到日誌。在SQL Server中唯一不會被記錄到日誌的操作是TempDB中的資料列版本設定。 Truncate
Time of Update: 2017-01-19
誤區 #18:如下多個有關FileStream的誤區全部錯誤18 a)FileStream資料可以在遠程儲存 不能,由於FileStream資料容器(指的是存放FileStream檔案的NTFS檔案夾,杜撰出來的術語)必須像資料檔案或記錄檔那樣符合本機存放區策略-也就是說,這個資料容器必須放在對於運行SQL Server的Windows
Time of Update: 2017-01-19
其實我之前已經有文章詳細解釋了頁校正和:How to tell if the IO subsystem is causing corruptions? 誤區 #17:幾個有關頁校正和的誤區坊間流傳的基本是錯誤的 17 a)頁校正和(Page CheckSum)在從SQL Server 2000或7.0升級上來之後自動開啟 其實不是,從舊的執行個體升級上來的資料庫不會自動開啟頁校正和,除非你顯式使用ALTER DATABASE
Time of Update: 2017-01-19
誤區 #16:多個關於資料的損壞和修複誤區 坊間流傳的很多版本都不正確 我已經聽過很多關於資料修複可以做什麼、不可以做什麼、什麼會導致資料損毀以及損壞是否可以自行消失。其實我已經針對這類問題寫過多篇博文,因此本篇博文可以作為“流言終結者”來做一個總結,希望你能有收穫。 首先,對於資料修複可以做什麼,不可以做什麼,我已經寫過一篇博文Misconceptions around database repair涵蓋了13個誤區—從不用DBCC
Time of Update: 2017-01-19
誤區 #15:CheckPoint只會將已提交的事務寫入磁碟 錯誤 這個誤區是由於太多人對日誌和恢複系統缺少全面的瞭解而存在已久。CheckPoint會將自上次CheckPoint以來所有在記憶體中改變的頁寫回磁碟(譯者註:也就是髒頁),或是在上一個CheckPoint讀入記憶體的髒頁寫入磁碟。無論事務是否已經提交,其所影響的頁都會在Checkpoint時寫回磁碟。但對於TempDB來說例外,因為TempDB的Checkpoint的事件周期中並不包含將髒頁寫回磁碟的步驟。
Time of Update: 2017-01-19
誤區 #14.清除日誌後會將相關的LSN填零初始化錯誤 當記錄檔在手動增長,自動成長和建立時都會進行填零初始化操作。但是請不要把這個過程和定期清除日誌的過程搞混。日誌截斷僅僅意味著將一個或多個VLF標記為不活動以便被重複使用。在日誌清除的過程中,並沒有任何日誌被清除或是填0。“清除日誌”和”截斷日誌”意思是一樣的,但都屬於用詞不當,因為在這個過程中日誌的大小不會有任何改變。
Time of Update: 2017-01-19
誤區 #13.在SQL Server 2000相容模式下不能使用DMV錯誤 對於相容模式已經存在了很多誤解。80的相容模式的資料庫是否意味著能夠附加或恢複到SQL Server 2000資料庫?當然不是。這隻是意味著一些T-SQL的文法,查詢計劃的行為以及一些其它方面和SQL Server 2000中行為一樣(當然,如果你設定成90相容模式則和SQL Server 2005中一樣)。 在SQL
Time of Update: 2017-01-19
誤區 #12:TempDB的檔案數和需要和CPU數目保持一致錯誤 哎,由於上述誤區是微軟“官方”的建議,並且還有大量博文堅持這個觀點,這個誤區已經是老生常談。 但讓人困惑的是SQL CAT團隊給出的建議就是1:1,但這個建議是源自擴充方面的原理來說,而不是一個通用法則。因為他們所面對的大型客戶資料量伺服器和IO子系統都是大部分人沒有機會遇到的。