Willeam's Blog http://blog.yam.com/willeam BizTalk Server,ASP.NET,SQL Server心得分享日誌(技術來自 ) zh-tw blog.yam.com All Rights Reserved 從Store procedure寫入event log 通常我們在寫.net程式時,習慣會將try..catch所攔截到的錯誤寫入到系統的event log,讓我們可以有統一介面去查看各種不同的錯誤訊息.<br />這種輸出錯誤訊息到event log的手法,其實在Store procedure也可以做到,只要透過此語法就可以.<br /><br /><span style="color: #ff0000"><strong>master..xp_logevent 50001, '錯誤訊息內容', 'ERROR'</strong></span><br /><br />輸出後,在event log可以看到此畫面.<br /><img alt="" src="http://pics13.blog.yam.com/19/userfile/w/willeam/blog/14ab1ac5352775.jpg" /><br /><br />裡面則是我們輸出的錯誤訊息.<br /><img alt="" src="http://pics13.blog.yam.com/19/userfile/w/willeam/blog/14ab1ac5c0c449.jpg" /><br /><br />store procedure最麻煩的就是進行debug,雖然我們可以在SQL Studio裡面debug,但是有時候手動run與透過background job run還是有一點差異,然後又無法像.NET 元件一樣從Visual Studio去attach process的方式monitor元件執行狀況,所以若可以在store procedure執行時,將一些訊息丟出來event log,多多少少可以了解運作的狀況.<br /><br /> 這種輸出錯誤訊息到event log的手法,其實在Store procedure也可以做到,只要透過此語法就可以.

master..xp_logevent 50001, '錯誤訊息內容', 'ERROR'

輸出後,在event log可以看到此畫面.


裡面則是我們輸出的錯誤訊息.


store procedure最麻煩的就是進行debug,雖然我們可以在SQL Studio裡面debug,但是有時候手動run與透過background job run還是有一點差異,然後又無法像.NET 元件一樣從Visual Studio去attach process的方式monitor元件執行狀況,所以若可以在store procedure執行時,將一些訊息丟出來event log,多多少少可以了解運作的狀況.

]]> http://blog.yam.com/willeam/article/23991972 SQL Server Thu, 17 Sep 2009 11:40:33 +0800 清除過大的Database log <p>當資料庫run了一段時間後,通常log檔都會很大,而且比原本儲存原始資料的database還大,這時候可以利用此語法清除log.<br /><br />BACKUP LOG [資料庫名稱] WITH NO_LOG <br />DBCC SHRINKDATABASE ([資料庫名稱], 10)&nbsp;<br /></p> 當資料庫run了一段時間後,通常log檔都會很大,而且比原本儲存原始資料的database還大,這時候可以利用此語法清除log.

BACKUP LOG [資料庫名稱] WITH NO_LOG
DBCC SHRINKDATABASE ([資料庫名稱], 10) 

]]> http://blog.yam.com/willeam/article/11585814 SQL Server Sat, 01 Sep 2007 00:11:10 +0800 透過DTS 輸出int型別資料到File,卻產生多位小數點 <p>當你利用 DTS來轉出資料庫資料到文字檔時，假如來源資料裡有某個欄位是數值型別的話，可能需要特別注意一下。</p><p>因為，DTS會先根據資料來源來產生虛擬欄位在即將輸出的文字檔裡，此虛擬欄位並無資料型別(因為是輸出到文字檔，而非資料表)，所以通常只是交代此欄位是否要加引號(quote)或不加引號，還有長度為何。這時候若在資料的轉換過程中有需要進行數字的處理，如將來源除以10後輸出，這時候可能會發生一個問題，原本應該輸出0.4的結果卻輸出0.400000002 這個怪樣子。</p><p>我個人猜想可能是因為目的欄位有設定長度的關係，而且因為目的欄位沒有型別，所以原本應該0.4的數字卻變成0.400000002，這時候必須在資料轉換過程中先將0.4以 CStr()函數強制轉型成純文字在輸出，這樣一來因為是純字串的輸出就不用怕他會搞鬼了。</p><p /> 當你利用 DTS來轉出資料庫資料到文字檔時，假如來源資料裡有某個欄位是數值型別的話，可能需要特別注意一下。

因為，DTS會先根據資料來源來產生虛擬欄位在即將輸出的文字檔裡，此虛擬欄位並無資料型別(因為是輸出到文字檔，而非資料表)，所以通常只是交代此欄位是否要加引號(quote)或不加引號，還有長度為何。這時候若在資料的轉換過程中有需要進行數字的處理，如將來源除以10後輸出，這時候可能會發生一個問題，原本應該輸出0.4的結果卻輸出0.400000002 這個怪樣子。

我個人猜想可能是因為目的欄位有設定長度的關係，而且因為目的欄位沒有型別，所以原本應該0.4的數字卻變成0.400000002，這時候必須在資料轉換過程中先將0.4以 CStr()函數強制轉型成純文字在輸出，這樣一來因為是純字串的輸出就不用怕他會搞鬼了。

]]> http://blog.yam.com/willeam/article/5140716 SQL Server Sat, 30 Jul 2005 01:10:43 +0800