在CYQ.Data 數(shù)據(jù)框架支持上Access時(shí)，以top max(id)為分頁方式。

在秋色園沒有多少文章的情況下，基本上維持著正常的秩序。

直到秋色園在進(jìn)化版本時(shí)，多字段排序的情況出現(xiàn)，如：order by 字段1，字段2。

原始的 top max(id)已無法正常的顯示分頁的數(shù)據(jù)了。

top max(id)只適用于單字段排序，無法適用多字段排序，自然就無法通用了。

故CYQ.Data的分頁方式，從top max(id) 改成常規(guī)的 not in方式。

一開始沒有測試數(shù)據(jù)量，隨便點(diǎn)點(diǎn)感覺分頁也挺快的。

后經(jīng)秋色園的文章上到三四千時(shí)，發(fā)現(xiàn)分頁奇慢，已無法讓它在存活了，于是把它給滅了。

滅掉not in方式，換上了3次top，分起頁來那是刷刷刷，速度快的不行。

于是這種方式，一直存到至今，當(dāng)前3-4萬的數(shù)據(jù)中，分頁雖不快，但勉強(qiáng)也能接受。

Access在并發(fā)寫數(shù)據(jù)上，有著不可估計(jì)的錯(cuò)誤，從秋色園的后臺異常日志記錄中，最常出現(xiàn)的錯(cuò)誤：

Could not update; currently locked.SQL:Update Blog_User Set VisitCount=64359+1 where ID=111

這個(gè)異常一早出現(xiàn)次數(shù)比較多，后來通過程序優(yōu)化之后，通過在內(nèi)存計(jì)數(shù)，隨機(jī)概率才更新數(shù)據(jù)庫方式，每天平均就2-3次的情況出現(xiàn)。

Unspecified errorSQL:select count(*) from Blog_Content where Year(CreateTime)=2011 and Month(CreateTime)=1 and UserID=67 and TypeID=0 and IsPub=true

這個(gè)異常平時(shí)不出現(xiàn)，一出現(xiàn)秋色園就基本打不開了，而且會占好長時(shí)間，網(wǎng)上搜索的答案好就是什么臨時(shí)文件滿了，擠不進(jìn)去導(dǎo)致的。

其實(shí)一開始是有考慮用SQLite的，不過由于時(shí)間比較緊，而且框架對于一些函數(shù)的通用性，只處理了Access/MSSQL/Oracle三種，啥意思呢？

就是同一個(gè)函數(shù)，在不同的數(shù)據(jù)庫時(shí)，名稱，用法，都可能不同，好多其它支持多數(shù)據(jù)庫的系統(tǒng)，多數(shù)寫兩條或多條語句了，不同的數(shù)據(jù)庫版本提交不同的DLL復(fù)蓋。

而CYQ.Data在底層上進(jìn)行了處理，可以讓1條語句，自動解析成不同數(shù)據(jù)庫類型的語句，這樣就達(dá)到一種寫法，多處兼容的狀態(tài)。

由于SQLite和MySQL是最近版本新加的，所以還沒做兼容處理，加上感覺從Access向SQLite導(dǎo)數(shù)據(jù)不好導(dǎo)，所以就沒用了。

由于寄在人家子目錄里，所以除了FTP權(quán)限，其它啥權(quán)限都沒。

因此，最常見的文件夾壓縮也沒了。

所以呢，就用ICSharpCode.SharpZipLib.dll寫了個(gè)Zip在線壓縮，Access壓縮后還是能少好幾倍的大小的。

秋色園由于自定義了生命周期，于是有很多的統(tǒng)一關(guān)口，我只要輕松的把OnPost事件關(guān)口給操作，改成操作輸出：

很抱歉：系統(tǒng)正在升級，無法提交數(shù)據(jù)。

這樣就輕松避開了用戶對數(shù)據(jù)庫的寫操作了，又保證站點(diǎn)的正常訪問。

嘗試把數(shù)據(jù)導(dǎo)到本機(jī)測試一下，發(fā)現(xiàn)很多Memo類型的字段，都導(dǎo)不進(jìn)來??！

還得把數(shù)據(jù)庫對應(yīng)字段都改成nvarchar(max)才能導(dǎo)進(jìn)去。

導(dǎo)完又得把字段改回去，一改一導(dǎo)一動，花了不少時(shí)間。

運(yùn)行秋色園站點(diǎn)，發(fā)現(xiàn)首頁出不來，調(diào)度發(fā)現(xiàn)，少了個(gè)字段，重新導(dǎo)麻煩，只好寫sql更新。

再來發(fā)現(xiàn)秋色園的兩個(gè)系統(tǒng)分類失蹤了，花了不少時(shí)間查到原因，于是給補(bǔ)上了。

再后來，從本機(jī)的MSSQL向遠(yuǎn)程的MSSQL導(dǎo)數(shù)據(jù)了，由于有數(shù)據(jù)庫鏈接，自然也能導(dǎo)了，

一開始發(fā)現(xiàn)兩邊的字段類型有點(diǎn)區(qū)別，還得修正一下。

然后接著導(dǎo)，一直到現(xiàn)在才導(dǎo)了1萬多，還差2萬，所以我就在這寫文章了。

過程中，小小遇到另一個(gè)事情，由于自增ID開啟時(shí)，是無法導(dǎo)入ID的，

所以在創(chuàng)建表時(shí)，只好把自增加ID去掉，想導(dǎo)完數(shù)據(jù)后再補(bǔ)上。

卻發(fā)現(xiàn)，用SQL要補(bǔ)上不是件容易的事，最簡單的方式自然就是用IDE。

不過SQL Server Management Studio鏈接遠(yuǎn)程數(shù)據(jù)庫的話，幾百幾千的數(shù)據(jù)庫，

基本上夠卡死機(jī)子不用動了，更別說改好了。

錯(cuò)誤 0xc0202009: 數(shù)據(jù)流任務(wù): 出現(xiàn) OLE DB 錯(cuò)誤。錯(cuò)誤代碼: 0x80004005。
已獲得 OLE DB 記錄。源:“Microsoft SQL Native Client” Hresult: 0x80004005 說明:“Could not allocate a new page for database \'cyqdata\' because of insufficient disk space in filegroup \'PRIMARY\'. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.”。
(SQL Server 導(dǎo)入和導(dǎo)出向?qū)?