Not so...FRED is a public synonym (not in any schema). It's just Oracle JDBC wierdness with synonyms. I saw all kinds of wierd things in my testing.
Maybe you misunderstood my proposed fix...I'm proposing a way for you to GENERATE against a specific schema, but RUN without any schema specified. This means that the default schema (or synonym) for the user would be used.
I really think this would resolve the issue. I'm not proposing that you change anything about how your database is defined.
Jeff Butler
On 9/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
The includeSynonyms trick does not work with public synonyms for tables in other schemas. Your example is just an alias for a table in the same schema (HR.EMPLOYEES and HR.FRED are both in schema HR). We create synonyms only to reference tables in other schemas as though they were in our schema.We might be able to get by without synonyms, but not specifying a schema will simply not work, because we have 8 schemas that all have the same table names. Currently, Abator just uses the first table it finds, which doesn't correspond to the user's default schema. We don't want to hardcode the schema name into the abator configs because each developer uses a different one. We might be able to use an entity reference to store these externally, but that brings up another problem I found with Abator that may have already been addressed in SVN, but the entity resolver throws an exception rather than returning null for entities it doesn't recognize, so you can't define your own entities in the DOCTYPE.
