對Delphi TDBGrid中的SQL結果集進行排序，其中結果集包括Firebird RDB $ DB_KEY（Order By不工作）

我注意到一些奇怪的東西，我不太確定該怎麼做。下面的結果集基本上是我的應用程序寫入其日誌消息的表上的SQL Select語句的輸出。我已經編輯了諸如網站和任務細節之類的敏感資料，併爲您提供了字段數據類型而不是字段名，除了內置於Firebird表中的RDB$DB_KEY。 我希望您關注的是我列出的排列順序，儘管使用了在我的SQL中按照RDB $ DB_KEY排序。現在

Timestamp Field    Varchar Field   RDB$DB_KEY 
======================== ====================== ================= 
19.12.2013, 10:40:40.000 Site_BC DB_2 connected 00000083:00000100 
19.12.2013, 10:40:40.000 Site_BC DB_1 connected 00000083:000000fc 
19.12.2013, 10:40:40.000 DB_1 tasks completed 00000083:000000fd 
19.12.2013, 10:40:40.000 Site_A DB_2 connected 00000083:000000fe

，我可以發誓0進來的ASCII表1過，所以看起來行（假定排序中由RDB $ DB_KEY字段中的值升序）的順序沒有對我來說。

我做了一些基礎研究，顯然這個RDB $ DB_KEY字段是一個字節數組（雖然我不確定）。我試着把它作爲一個varchar和一個字符，但它似乎火鳥Cast不支持從這個數據類型的轉換。

任何人都可以幫助我得到這些行正確排序嗎？我知道我可以添加另一列整數數據類型，然後按此排序，但我想我會問，以防萬一有人知道如何通過名爲RDB $ DB_KEY的混合祝福進行排序。

我正在使用Firebird 2.5版。

來源

2013-12-19 Sam

您選擇的RDB$DB_KEY輸出僅格式化爲在客戶端上呈現。這不是實際的密鑰（！）。實際的RDB$DB_KEY（對於表）是八字節數組（或64位數）。

現在就排序而言，我並不是100％確切的實現，但RDB $ DB_KEY是big-endian，或者這個演示文稿是big-endian）。在big-endian 0x0100之前0x00fc（在小尾數將是0x0001和0xfc00）。

但正如我已經在評論中指出的那樣，訂購RDB$DB_KEY幾乎沒有任何意義。 RDB$DB_KEY表示記錄的物理位置的「快照」，僅在交易期間才真正有效（簡化）。 RDB$DB_KEY多個記錄的順序通常不會反映插入順序（如果可能，該順序在備份和恢復後可能會不同），而只是存儲上的相對位置（對於當前可見的記錄版本）。

來源

2013-12-19 10:59:41

關於備份和恢復的觀點讓我相信不要使用它。否則，由於它不遵守Order By子句的規則（如果它不能被排序，那麼在實現中存在一個錯誤），否則我會將這個big-endian的東西稱爲實現中的一個錯誤。 [1]。謝謝。 – Sam

@Sam它不是一個錯誤：你可以通過'RDB $ DB_KEY'命令;它的（一致的）排序不符合你的期望是完全不同的。 –

我可以「排序」但它不按升序排序，因此它不起作用，因此它是一個錯誤。如果ASCII表是一夜之間改變和突然的字母「C」開頭並不意味着C中的字母「A」現在應該在一個排序結果集先於。單個字段值的編碼/解碼的內部並沒有改變什麼「升序排序」意味着對用戶的意義，因此在ORDER BY實現被打破。它不符合規範，或者在事實上重新定義了排序的時候，它被錯誤地提供了排序功能。 – Sam

這是一個可惜沒有人回答，你必須選擇「這是你的問題」的答案。

order by cast(rdb$db_key as blob)

我可能是錯的，但我懷疑FB默認排序時只使用第一個字節排序db_key。

來源

2017-02-14 15:37:53

對Delphi TDBGrid中的SQL結果集進行排序，其中結果集包括Firebird RDB $ DB_KEY（Order By不工作）

回答

相關問題