Hello Jim,

Thursday, April 29, 2004, 11:39:30 PM, you wrote:

> Leyne, Sean wrote:

>>Are you suggesting that there would be persisted entries in the
>>RDB$Fields table (and the like) for the external tables?
>>
>>
>>
> Yes.

> Most of the engine and all of the tools are dependent on the system
> tables for metadata. With extreme effort, the primary system tables
> (RDB$RELATIONS, RDB$FIELDS, RDB$RELATION_FIELDS) could be coersed to be
> unions of hard tables and dynamic metadata extracted from external data
> sources. But I seriously doubt the investment would reap commensurate
> returns. An external table declared as more or less a select statement
> against a named external data source could be easily refreshed (if
> necessary) at a small cost of a full blown heuristic variants on the
> core system tables. The path of least resistence is to populate the
> existing system tables with a snapshot of the external data source.
> Nothing would require that the external data source return anything but
> the closest approximation of the current external datatypes, but the
> Firebird system tables would reflect the state of the external data
> source at the time of declaration. Not perfect, but the effects of
> stale metadata are worst an annoyance, and at best inconsequential.

> If somebody has a beast clever way to do a runtime merge of hard
> internal metadata and soft external metadata, I'm all ears.

Apparently, the SQL-2003 standards seems to agree with Jim. There is
a 500 page document that outlines how the external data should be
managed(SQL/MED ISO/IEC 9075-9:2003). The document talks about
Foreign-Data Wrappers, what its API should look like, the metadata
information, etc...

--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)