I think for a future effort that the whole column naming scenario should be
normalized one step further. The SQLVar structures should pass a column key
and then for the particulars of that key they can be looked up and cached on
the client. The same should also happen in the metadata/BLR. This way it can
be rather easy to change a column name if there is only one place that it is
stored and all references to it are by a surrogate ID.

This is assuming lengthy column names will be used. I also think that a
varchar structure should be used instead of a CHAR so that the significant
bytes are explicitly defined regardless of content.

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.

Oh well, I probably should leave this up to the experts...

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com