一種可能是數據庫文件在增加的時候超時了，而不是平常常以為的具體的SQL語句超時。把 FILEGROWTH 設置為一個更低的值，可能會恢復這個錯誤。
FILEGROWTH 的設置就是在數據庫的 Enterprise Manager 中，對數據庫的屬性的如下窗口進行設置：
一旦你的數據庫文件大了後，上述超時就可能出現。這時候不要簡單地以為服務器壓力太大了。也許就是你的一個設置導致了超時。
默認SQL Server 在數據庫文件滿了後，是自動增加原數據庫文件的10%大小，用來繼續使用，解決方法就是把上述的文件增長這裡設置為一個更低的百分比或者直接指定增加多少兆字節。 如果是默認的10%的話，可能導致的問題在於數據庫大小一次性需要增長數G,www.aspxuexi.com,ASP學習網。
另外:不僅是數據文件滿會導致此問題，日志文件滿也一樣。
某一條數據更新語句在數據庫或日志文件即將滿的時候執行，數據庫增長的IO操作會導致延時，此延時會阻塞其他數據庫操作，連鎖反應，形成blocking。
其實此時找出一條正在阻塞的更新語句，在查詢分析器中執行，此時是沒有超市時間的。忍過幾分鐘，當這條語句執行完後，數據文件就會增長完成，所有的blocking也就解開了。
微軟的 文章招錄:(由機器人翻譯)
替代方法
要變通解決此問題, 請使用下列方法之一：
• 手動展開數據庫。 以手動, 展開數據庫使用 ALTERDATABASE 語句或 SQLServer 企業管理器。
• 增大的應用程序， 以便有時間來展開數據庫服務器請求 DML 客戶查詢超時值。 DML 提示數據庫以展開。
例如, 如果使用 SQL 查詢分析器, 默認查詢超時值為 0 （無限）。 如果正在使用默認值, 您不會遇到此問題。 如果不使用默認值, 增大查詢超時值。
可用於其他應用程序 （無論它們是否基於 Web）, 您在應用程序進行更改。 例如, 如果您使用 ADO, 可更改 CommandTimeout 屬性 連接 或 Command 對象。
• 確定服務器上數據庫擴展多長時間。 確定此, SQL 查詢分析器中運行 ALTERDATABASE 語句， 然後查看狀態欄。 在您確定此, 設置客戶超時值為東西大於此值。
• 不要更改客戶超時值。 繼續執行測試自動擴展並查看多少擴展完成小於客戶超值中。 自動增長 選項設置為此新 （小） 值。
