At 12:12 PM 5/24/01 -0700, Jason Wharton wrote:

>
>One significant problem here is in keeping the associations between name and
>ID when doing stuff like a backup and restore. If upon restore you have a
>column receiving a different ID than it previously had then the BLR of a
>trigger referring to that column just got all messed up. I'm not sure how
>you would solve this issue but it is a wrench in the works for sure. Am I
>correct to assume restore does not rely upon being able to compile the
>trigger from the source again? It just goes off the BLR that was previously
>there? Perhaps the backup would do a parse of the BLR and define it using a
>column by name instead of a column by ID and then restore it by placing the
>by name references back to by ID.
>

Table and field ids are explicitly limited in score to a single
database attachment. They are not persistent. Any apparent
stability between attachments is an artifact of implementation
and should not be relied upon. Ids exist for the convenience
of query languages, dynamic SQL, and like. Anyone who uses
ids for any other purpose should expect divine retribution
of some horrible kind.

Jim Starkey