- MSSQLServer中從INSERT中返回IDENTITY
遇到這樣一個問題，一張表只有一個PK且是IDENTITY，在向表中插入數(shù)據(jù)后需要得到插入記錄的PK值。剛開始使用鎖表的方法，比較繁瑣，后來發(fā)現(xiàn)下面的方法：
SET NOCOUNT ON;
INSERT INTO USERMST (Name) VALUES (‘username‘);
SELECT @@IDENTITY
關(guān)鍵在第一行上，設(shè)置不要返回受操作影響的行數(shù)。執(zhí)行上面的SQL后，可以從ResultSet中得到ID的值，也就是SELECT @@IDENTITY取得的最新的IDENTITY值。
參考：http://www.microsoft.com/china/MSDN/library/data/sqlserver/FiveWaystoRevupYourSQLPerformanCE.mspx
在ORACLE中也有類似方法：（當(dāng)然，也可以從Sequence中得到）
Declare
userrow USERMST%rowtype;
Begin
INSERT INTO USERMST (Id,Name) VALUES (idseq.nextval,‘username‘)
RETURNING Id,Name INTO userrow.Id, userrow.Name;
End;
Oracle Release 2之后可以簡化為
INSERT INTO USERMST (Id,Name) VALUES (idseq.nextval,‘username‘)
RETURNING Id,Name INTO userrow;
參考：http://www.cnblogs.com/sunsonbaby/archive/2005/02/01/100547.html
- MSSQLServer中的事務(wù)鎖
還是同一個項(xiàng)目，遇到一個事務(wù)處理的問題。預(yù)約者通過網(wǎng)站預(yù)約參加會議，管理者可以變更會議參加的人數(shù)額度及刪除預(yù)約者，這時(shí)候，就產(chǎn)生了數(shù)據(jù)同步的問題：預(yù)約者和管理者同時(shí)變更數(shù)據(jù)，可能造成一方拿到“臟數(shù)據(jù)”，而使得系統(tǒng)產(chǎn)生差錯。下面就是加鎖方法：
SELECT [columns] FROM [table] WITH (tablehints)
tablehints的可用參數(shù)如下：
HOLDLOCK 持有共享鎖，直到整個事務(wù)完成，應(yīng)該在被鎖對象不需要時(shí)立即釋放，等于SERIALIZABLE事務(wù)隔離級別
NOLOCK 語句執(zhí)行時(shí)不發(fā)出共享鎖，允許臟讀，等于READ UNCOMMITTED事務(wù)隔離級別
PAGLOCK 在使用一個表鎖的地方用多個頁鎖
READPAST 讓sql server跳過任何鎖定行，執(zhí)行事務(wù)，適用于READ UNCOMMITTED事務(wù)隔離級別只跳過RID鎖，不跳過頁，區(qū)域和表鎖
ROWLOCK 強(qiáng)制使用行鎖
TABLOCKX 強(qiáng)制使用獨(dú)占表級鎖，這個鎖在事務(wù)期間阻止任何其他事務(wù)使用這個表
UPLOCK 強(qiáng)制在讀表時(shí)使用更新而不用共享鎖
同樣也可以通過T-SQL的事務(wù)語句或者ADO的控件參數(shù)設(shè)置事務(wù)級別，詳細(xì)請看下面鏈接。
參考：http://www./database/mssql/jqapp/159.htm
還有一篇http://bbs.ustc.edu.cn/cgi/bbscon?bn=DataBase&fn=M41f36292&num=3378
對應(yīng)的，Oracle中比較常用的方法：
SELECT [columns] FROM [table] FOR UPDATE [NOWAIT]
- MSSQLServer中的集計(jì)運(yùn)算
接觸了一個新的系統(tǒng)，中間運(yùn)用了很多集計(jì)運(yùn)算，卻沒有用平常使用的SUM，COUNT函數(shù)，而是用了一個GROUP BY的關(guān)鍵字WITH ROLLUP/CUBE，加上這個關(guān)鍵字，將會對分組后的數(shù)據(jù)按照層次進(jìn)行集計(jì)運(yùn)算，并將數(shù)據(jù)直接付在所集計(jì)數(shù)據(jù)之后，對于報(bào)表數(shù)據(jù)的處理有很大的幫助。對于ROOLUP和CUBE的區(qū)別在于，ROLLUP按分組層次來運(yùn)算，而CUBE是按所有可能的組合來運(yùn)算。下面給個例子，數(shù)據(jù)如下：
Item Color Quantity
-------------------- -------------------- --------------------------
Table Blue 124
Table Red 223
Chair Blue 101
Chair Red 210
使用集計(jì)運(yùn)算SQL，中間的CASE語句是為了去掉集計(jì)產(chǎn)生的NULL值，可以去掉看一下有什么區(qū)別。
SELECT CASE WHEN (GROUPING(Item) = 1) THEN ‘ALL‘
ELSE ISNULL(Item, ‘UNKNOWN‘)
END AS Item,
CASE WHEN (GROUPING(Color) = 1) THEN ‘ALL‘
ELSE ISNULL(Color, ‘UNKNOWN‘)
END AS Color,
SUM(Quantity) AS QtySum
FROM Inventory
GROUP BY Item, Color WITH ROLLUP
產(chǎn)生結(jié)果集：
Item Color QtySum
-------------------- -------------------- --------------------------
Chair Blue 101.00
Chair Red 210.00
Chair ALL 311.00
Table Blue 124.00
Table Red 223.00
Table ALL 347.00
ALL ALL 658.00
如果使用WITH CUBE，那么結(jié)果集還會多出下面兩行記錄
ALL Blue 225.00
ALL Red 433.00
注意觀察，紅色的部分，是ROLLUP對Color分組層進(jìn)行運(yùn)算的結(jié)果，綠色部分則是對Item層的，而CUBE會將Color與Item的任意一種組合都進(jìn)行運(yùn)算。是不是很方便呢。
- 數(shù)據(jù)庫中的Collate
Collate關(guān)鍵字指定了數(shù)據(jù)庫使用的效驗(yàn)方式。簡單來說，就是數(shù)據(jù)的比較規(guī)則，比如大小寫敏感，長度敏感等等，Collate可以在建數(shù)據(jù)庫、表、甚至在SQL實(shí)行時(shí)指定。這次遇到的問題是因?yàn)楸容^2個數(shù)據(jù)庫中表字段，但2個數(shù)據(jù)庫使用的默認(rèn)Collate不一樣，導(dǎo)致類型轉(zhuǎn)換錯誤，比較失敗，SQL報(bào)錯。通常不太會注意這類問題，但是遇到導(dǎo)入或者分布式的數(shù)據(jù)庫時(shí)或許會出現(xiàn)問題。
下面附帶查詢默認(rèn)數(shù)據(jù)庫以外的SQL語句
SELECT 字段名 FROM [數(shù)據(jù)庫名].[表所有者名].表名
比如：SELECT TA.C1, TB.C2 FROM TableA TA , otherdb.dbo.TableB TB
其中，表所有者名可以省略，變?yōu)閛therdb..TableB，當(dāng)然，當(dāng)前連接用戶要有訪問otherdb數(shù)據(jù)庫的權(quán)限。
|
