05.04.2013 8:04, Dmitry Yemanov wrote: > So far I can think of two solutions: > > 1) Add two symmetric built-in functions: DBKEY_TO_CHAR and > CHAR_TO_DBKEY. The former one would return the predefined hex-encoded > textual representation of the DBKEY while the latter one would perform > the opposite transformation. So one would need to SELECT > DBKEY_TO_CHAR(RDB$DB_KEY) ... (or just copy'n'paste from the error > message) and then SELECT ... WHERE RDB$DB_KEY = CHAR_TO_DBKEY(?).
AFAIK, DBKEY has type CHAR(X) CHARACTER SET OCTETS. CORE-3039 is closed with resolution "won't fix". Obviously, there is no need for human readable form of such fields. > 2) Add pseudo-column RDB$RECORD_NUMBER which would return rpb_number as > BIGINT (can be easily converted from/to text). Modify the engine so that > search for RDB$RECORD_NUMBER would work similar to the searching for > RDB$DB_KEY i.e. use a fast positioned table access. Unfortunately, DBKEY has variable size and not always fit into int64. -- WBR, SD. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel