Zeoslib Portal

bug report: Metadata issue with ADO
catalog and schema context lost when updating data in zeos datasets

[problem]
i have a couple of databases - db1 and db2 on the same server.
i connect to server via zConnection with ADO protocol and say that
mine current database is db1 (with connection string or
directly with USE query - does not matter).

next i take a zQuery named dsQuery, set its SQL into:
'select * from db2.dbo.tablenamex',
set it's RequestLive to true
(or readonly to false if you like) and open it.
next i do dsQuery.open, focus some record,
update it executing dsQuery.edit and modifying fields.
and when we do dsQuery.post it internally forms sql string like:
'update tablenamex set fieldname=_value_, ... where keyfield=_value_'
and so on, but it puts 'tablenamex' there instead of 'db2.dbo.tablenamex'.
thus we can not modify data in database other then current using
zQuery with .edit and .post.

to make it possible it is enough to uncomment the following strings:

[suggested solution]
(scope)
======== [dbc\ZDbcAdoMetadata.pas] ========
function TZAdoDatabaseMetadata.GetColumns(...): IZResultSet;
(origin)
{
Result.UpdateStringByName('TABLE_CAT',
''{GetStringByName('TABLE_CATALOG')});
Result.UpdateStringByName('TABLE_SCHEM',
''{GetStringByName('TABLE_SCHEMA')});
}
(change into)
{
Result.UpdateStringByName('TABLE_CAT',
GetStringByName('TABLE_CATALOG'));
Result.UpdateStringByName('TABLE_SCHEM',
GetStringByName('TABLE_SCHEMA'));
}

but WHY this lines were commented that way is still a mistery for me.
so i understand that uncommenting it may lead not only to enabling
the features i need but also to damaging something i do not expect.

thus i ask respected developers to check it out and to make a
decision how to enable such a behaviour in a safe way.

[platform notes]
zeosdbo-6.6.1-beta
protocol: ado
delphi7
Microsoft SQL server 2000
field kind = image

best wishes.

Well,

I have bad news. I'm not able to test this.

BUT as this seems to be the right way to handle 'Getcolumns' I DO commit the change. I think problems resulting from this change should be solved in another way.

Once again, please get the test suite running ASAP for ADO. That way we might catch trouble arising from this kind of changes.

Committed in rev. 260