Thanks, putting the schema(s) into the query is what's happening right now -- I just wanted to find out if there was a better way (more DB2-ish). It appears not.

I'll just put that idea aside for now. My plan is to set the schema when the database connection is made, so that, for most part, I don't have to have the schema in the query or command.

Is that making things too tidy?

talexb:

I don't know if DB2 allows insertable views or not. But if so, you could make some views from the most-used schema to the objects in the lesser-used ones, bypassing the issue...

use food

create view food.orchard
  as select * from trees.orangeTrees

select A.apples, B.oranges
from fruitSalad A
join orchard B on A.compareKey = B.compareKey
[download]

...roboticus

Interesting idea, thanks. I haven't really considered creating more DB2 views since I'm relatively new to DB2 (well, I think PostgreSQL has them as well, but since I'm not a full-time DBA, I get lazy), but that might be an approach to consider. I've already discovered db2expln and I'm a regular visitor to IBM Boulder's DB2 web site with on-line documentation, so that's definitely something to consider.

My goal is to 'de-complicate' the source code, and I'm trying to do that by conflating some of the routines into fewer, slightly smarter routines; by simplifying the SQL that's used; and by grouping related routines into their own modules, rather than have a couple of monster modules that get pulled into just about every script.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds