1、判斷輸入的路徑在服務器上是否存在：
例如，要在客戶端執行一個創建數據庫的程序，數據庫要在服務器上創建，但路徑可以手工輸入，這時就面臨一個判斷自已現在輸入的路徑在服務器上是否存在的問題，免得在執行Create Database SQL時才報錯：找不到路徑。
具體方法如下：
exec master..xp_cmdshell 'dir E:DATA' ，在查詢分析器中執行此段SQL，如果存在此路徑，會輸出此路徑下的所有文件與文件夾信息，還有此盤的可用字節數與已此文件夾的字節數(圖1所示);如果此路徑不存在，則輸出信息如圖2所示，提示“找不到文件”。
但是，當路徑中含有空格時，如C:Program Files，直接用exec master..xp_cmdshell 'dir C:Program Files'，系統返回結果會如跟圖2顯示一樣，我們需要做額外處理，才能得到正確的返回結果：
(1)exec master..xp_cmdshell 'dir "C:Program FilesMicrosoft SQL ServerMSSQL"'
這種寫法，在查詢分析器中直接執行是沒有問題的，也能返回正確結果，但如果放到程序中執行：
SQL.Add('exec master..xp_cmdshell ''dir "C:Program FilesMicrosoft SQL ServerMSSQL"'')，Open時就會報錯，不能執行。
為什麼呢???
(2)我們接下來查看SQL聯機幫助，對XP_CMDSHELL的描述如下：
xp_cmdshell {'command_string'} [, no_output]
參數
'command_string'
是在操作系統命令行解釋器上執行的命令字符串。command_string 的數據類型為 varchar(255) 或 nvarchar(4000)，沒有默認值。command_string 不能包含一對以 上的雙引號。如果由 command_string 引用的文件路徑或程序名稱中有空格，則需要使用一對引號。如果使用嵌入空格不方便，可考慮使用 FAT 8.3 文件名作為解決辦 法。
no_output
是可選參數，表示執行給定的 command_string，但不向客戶端返回任何輸出。
幫助文件提示我們要用一對引號將文件路徑或者程序名稱包起來，將整個路徑包不起來不會報錯，那我就將帶有空格的單步路徑包起來試試，看看行不行，執行 如下SQL：SQL.Add('exec master..xp_cmdshell ''dir C:"Program Files""Microsoft SQL Server"MSSQL'')，這樣Open時果然不報錯了，看來查詢分析器的語法檢查與我們的Query自己的語法檢查還是有一定區別的，不能等同的。因此，碰到路徑中帶空格的情況，正確的寫法還是：
exec master..xp_cmdshell 'dir C:"Program Files""Microsoft SQL Server"MSSQL'
這同時說明SQL幫助文件中的綠色字體部分 command_string 不能包含一對以上的雙引號 的描述是不正確的，看來SQL Server幫助文件與產品也出現了“規格與程序不相符”的問題了，呵呵......
2、清空數據庫的日志文件
問題的引出：我們的切割過程就是將單據數據中某個日期以前的數據先復制到新的數據庫中(select ... into ...)，然後再將原來數據庫中的這些數據刪除,這樣操作在數量量很大的數據庫上時，其日志文件的增長也是驚人的：我復制一個48萬條記錄的表時，最後發現僅這一個表的操作就使新數據庫的日志文件增加了170MB，如果不加清理，那就會被日志文件占用大量寶貴的磁盤空間。況且，我們轉移到的新建數據庫的作用也只是用來查詢，以後不會有任何Insert、Update、Delete操作的，要這些日志文件沒有什麼用處，因此必須在向它轉移數據的過程中做一些縮小日志文件的處理，怎麼辦??問題由此而生...
(1)處理過程中不記錄日志
設置方法如下：企業管理器中打開對應數據庫的“屬性”，頁框“選項”中將“模型”改為“簡單”。這樣設置的結果是對此數據庫的任何操作都將不記錄事務日志。對應的SQL為：EXEC sp_dboption @pdbName, 'trunc. log on chkpt.', 'TRUE'
但是，我們經過測試發現：啟用此功能後，我們在對這個數據庫操作時，就不能用事務操作了，程序執行到BeginTranSaction時就報錯，不能執行下去，由於我們不能在對此庫的操作中保證100%的正確性，因此我們還需要事務，因此這種方法適用空間有限，也不能滿足我們程序的需求。
我們還得繼續查找.....
(2)處理過程中允許記錄日志，但要對日志文件進行處理，時時縮小它。
SQL Server的聯機幫助告訴我們：
在下列情況下，日志文件的物理大小將減少：
執行 DBCC SHRINKDATABASE 語句時。
執行引用日志文件的 DBCC SHRINKFILE 語句時。
自動收縮操作發生時。
下面我們逐個分析這三個方案：
① DBCC SHRINKDATABASE：收縮特定數據庫的所有數據和日志文件，包含我們的需求，但也大於我們的需求，此方案可用，但不要著急，給人的感覺是買了一件能穿的衣服，但尺寸大了些，穿在身上有點不舒服，我們接著分析以下兩個方案...
② DBCC SHRINKFILE: 收縮相關數據庫的指定數據文件或日志文件大小。與方案1的區別僅一字之差：“和”與“或”，相當於把方案1拆成兩步來執行，我們需要的就是收縮日志文件，因此，它對我們來說顯得比較合適，有點量體裁衣的感覺。但還有沒有更好的呢，我們來看第三個方案...
③自動收縮：數據庫也可設置為按給定的時間間隔自動收縮，服務器定期檢查每個數據庫中的空間使用情況。如果發現數據庫中有大量閒置空間，而且它的 autoshrink 選項設置為 true，SQL Server 就縮小該數據庫中的文件大小。它是周期性的執行DBCC SHRINKDATABASE，既然方案1已經是一件尺寸大了一些的衣服，則此方案就相當於又穿上了N件大尺寸衣服，一件就已經夠了，我還要那麼多干嘛呢??
綜合對比發現，方案2正是我們需要的。
DBCC SHRINKFILE ('+Trim(edDBMC.Text)+'_Log, TRUNCATEONLY)
經過這個語句處理以後，日志文件將回到它的最小狀態504KB，任何的日志記錄都將清空。
再結合我們的工具，復制完一個表之後，我們就執行方案2，處理過程中日志文件暫時占用的最大空間也就是處理最大數據表時產生的日志空間，但最後都將清空，顯示為500多KB，相對於龐大的數據文件而言，微之戡微.
