I am using Self-Service model v2.6 against Oracle 11g

When i create my llblgen project i get one connection string to connect to the database. So i can only access db objects that user has rights to. If i need to access tables in another schema i extend rights to that user to cross schema and get at those tables. Still one user, one connection string, one oracle server.

but now my client informs me that several key tables that i need access to are actually housed on another oracle server. Since this is a different machine i don't think there is a way i can get away with a single connection string any longer, regardless of the rights i extend to that user.

Is there a way to add another connection string in my llblgen project? Or is there a lower level way for oracle to handle this issue and make it transparent to llblgen?

The solution i came up with in the interim is not very appetizing: I create those db objects in the same db so llblgen project can see them and catalog them but then i use an auxiliary connection string and transactions to note when i need to reach out to this other db. It is ugly. Any suggestions?

No. You can't merge catalogs from different servers and generate one bucket of code. The recommended way is create two different LLBLGen projects, each one with the respective tables. In LLBLGen Designer, in Project options you can define different connection string key name for the two projects. At generated code, it should be easy to make it transparent:

using MyProject1;
using MyProject1.DataAccessAdapter;
using MyProject2;
using MyProject2.DataAccessAdapter;
...

// fetch/save tables in project 1
using (new MyProject1.DataAccessAdapter.DataAccessAdapter())
{
...
}

// fetch/save tables in project 2
using (new MyProject2.DataAccessAdapter.DataAccessAdapter())
{
...
}

You can create some custom factory to create the adapters so the code would be more transparent.

In LLBLGen v3.0 (now in beta, to release soon) you can do what you initially want (a project targeting multiple catalogs from different sources.