On Fri, December 21, 2012 11:59, Reinier Olislagers wrote: > On 18-12-2012 10:49, Tomas Hajny wrote: >> On Tue, December 18, 2012 09:35, >> michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: >>> On Tue, 18 Dec 2012, John wrote: >>>> you can't! That brings me back to the original point that either >>>> gettablenames has to operate on a known schema only (so you can supply >>>> the >>>> schema afterwards), or it has to supply the schema with the table >>>> name. >>> >>> I would opt for the latter, hence the soPrependSchemaName. >> >> Isn't something like a FullTableName property/method >> (connection-specific) >> a better solution (more universal, also catering for differences in >> construction of the full name with different database engines)? > No, because then you won't be able to get metadata using the same > mechanism for all connections. > If we create a FullTableName method (or property, with corresponding > tablenames collection etc), we should do the same for stored procedures, > views, and any other object a db supports. > Switching dbs would then be very problematic. > > The current mechanism has the advantage that it is extendable for > various dbs without too much effort... and is like other mechanisms > (e.g. the ADO.Net method of doing things).
I must have missed something, because my thoughts went exactly into the direction of simplifying switching from one database to another. Indeed, doing the same for all database objects would be IMHO beneficial too, but that's another story. My proposal was exactly this - whatever naming the respective DB provider requires natively when addressing objects, it would be reflected in this property (implemented in DB provider specific way). If it is 'SCHEMA_NAME.TABLE_NAME' with Oracle, so be it. If it is just 'TABLE_NAME' with MySQL - OK, no problem. Obviously, simple TableName field would still exist, but use of that field would then become DB provider specific (meaning that you could combine it with another selection condition like schema when querying the database dictionary or not depending on your needs). Obviously, accessing (querying) information about the database dictionary data is then DB provider specific too, but completely transparent to the end user. Then again, I might have missed something. I know Oracle fairly well (hopefully ;-) ), but certainly not all the other supported DB engines equally so (some of them not at all, with some of them just bare basics). Tomas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
