[fpc-devel] TField.FieldName: how about database and table names?

[Michael Van Canneyt]

On Wed, 18 Apr 2007, Bram Kuijvenhoven wrote:

> Hi!
> 
> The TField class from the db unit defines a FieldName. When using SQL queries,
> columns in the result set can be fully qualified using the form
> 'database.table.field'. Apparently FieldName only constitus the latter part.
> 
> When using an SQL query like
> 
>  SELECT * FROM myTable AS t1, myTable AS t2
> 
> how should one distinguish between t1.aField and t2.aField when using TField?

That depends on the engine. The engine assigns a unique name to each field
in the result set. This differs between engines, and can differ between
versions of the engine.

Run a query with an aggregate field on Interbase 6, run the same query on
Firebird 1. You'll see that the aggregate field is named differently.
 
> Is there currently a feature for this in the data model, or should we perhaps
> add two additional properties -- DatabaseName and TableName -- to a TSQLField
> (and TSQLFieldDef) descendant? (which then could be used by SQLDB etc.)

No, because:

1. DatabaseName you can get from the connection component. We don't support
   multi-connection queries, and AFAIK most engines don't support it
   either...

2. Tablename makes no sense if you execute a stored procedure.

Also, it would take a lot of extra queries to be able to retrieve these
values, and this would seriously impact performance. If there is anything
we should not compromise on, it's performance.

The only thing we can do is add the 'Origin' property such as Delphi has it.
And even then, this is of limited use.

Michael.