Dmitry,
> True, db_keys from aggregate views are problematic, but not for simple
> > joined views.
>
> Correct and it hasn't changed. I just meant that the view's DBKEY is not
> something separate, it simply a concatenation of the individual tables
> DBKEYs. You cannot select from a joined view using its combined DBKEY,
> you have to decode it into sub-parts and then use a particular table's
> DBKEY for retrieval. As long as we speak about identifying and locating
> *records*, IMHO it makes a lot of sense to forget about views and work
> with tables only.
>
Your choice. I vaguely recollect having used view db_key values in
debugging
something, but that sort of bug is no doubt gone, and besides, the values
are
still there.
The advantage of a function over conversion to int64 is that it can handle
changes
should the db_key ever need to change.. It could also format the DB_KEY in
its
components - pointer page number, offset on pointer page, offset in data
page index,
giving the whole thing some meaning.
Cheers,
Ann
------------------------------------------------------------------------------
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
