這里： 看到這里，我突然想到有可能是字符集不一樣造成的，打開表 原來問題出在排序 ...

在SQL Server中的字符類型都是有排序規則（collation）的，例如在下面的SQL語句中，我們建立了一個表變量@table_people，其中我們使用關鍵字COLLATE給列[Name]定義了排序規則"Chinese_PRC_CI_AS"，也給列[Description]定義了排序規則 ...

對於不規則的字符串數字排序，無法按照數字大的大小排序的原因是，字符串數字在數據庫中按照ASCII碼排序，從字符的第一個數字對比，首先就會將為首個數字相同的排在一起，在從這些字符串里面對比第二個數字，如下： 一組字符串為 ‘1’，‘2’,'10','11','3'； 不做任何處理的排序 ...

　　某天項目中寫了一句排序sql，但是發現每次執行的結果都不同，就是排序順序不一樣。 　　查詢了很多資料，也沒找到一個比較確認的理由，只是較多人認為是由於緩存的存在。引用一下別人的回答： 　　根數據庫系統的算法有關,早期版本的算法是自然的多個線程二分法,那個線程先查到滿足 ...

一同事在寫腳本時，遇到一個關於LIKE里面使用不同的變量類型導致查詢結果不一致的問題，因為這個問題被不同的人問過好幾次，索性總結一下，免得每次都要解釋一遍，直接丟一篇博客豈不是更方便！其實看似有點讓人不解的現象背后實質跟數據類型的實現有關。 下面我們構造這樣一個類似的簡單案例 ...

寫代碼中的某一天，我寫下了如下的代碼： 　　　　　　　　String sql = "select * from info info , info_extend extend where info.id = extend.infoid ...

...

由於同事誤操作，將數據的坐標系統搞混亂了。打開數據后顯示“警告：范圍不一致！一個或多個已添加的圖層的范圍與關聯的空間參考信息不一致。在此類圖層上重新投影數據可能會導致異常行為。” 再看其他圖層默認參考系統是投影坐標，3度分帶，38帶，有帶號 ...