Existing table names not schema-qualified

Dan Guzman

I get an invalid object name error when I specify an existing data source. Looking a trace, I see the source table is not schema-qualified during the SELECT COUNT_BIG(*) query. I there a setting or work-around for this issue?

Chris.Allen

Thanks for your question.

Your schema here is a non-dbo schema is it?

If yes then it is a known issue and as specified above it happens when the existing source is non-dbo schema.

So I have logged this as a bug in our internal tracking system whose tracking id is SDG-1068.

Our development team will look into this and I will update you as soon as this is fixed.

Again thanks for your patience and apologies for any inconvenience this issue has caused.

ForteUnited

Chris,

Please tell me this has been fixed. The tool doesn't work with tables not in the dbo schema!? Cmon, that is ridiculous. This was originally posted back in Sept. 2014. It is now the end January 2015 and I'm still running into this issue. Please tell me I am doing something wrong....

I need to this work.

Thanks

kalo

Is this likely to be fixed - as I make extensive use of non-dbo schemas , this prevents me from using what is otherwise a great tool from refreshing data from production to staging for test scenarios.

It is a bit odd that it the tool actually previews the data from the non-dbo schema table the user wants to pull from only then to say that it is an 'Invalid Object name' at the point of attempting the generation.

Regards.

scanner2001

We have submitted this as a bug last year, and just recently I contacted support about this as well.
The issue is around the statement: select count_big(*) from <table name>, where table name is not prefixed with the owner (schema), which in turn defaults to dbo.
You can verify this by running a trace against the source database.
The work around that was suggested to me by RedGate support was to move all of the data into a "dbo", which is completely unreasonable and unfeasible.
What I have done is created views in the dbo schema for the source tables that are not in the non-dbo schema, which are essentially "select * from <schema>.<table>".
There are obvious holes in this approach, but it works for my particular cases.

ucmueller

We downloaded the trial and i stumbled over this issue after 5 minutes testing. Bummer!
I like very much what i have seen so far but this is a real show-stopper.
We also make extensive use of non dbo schemas.
Why can a simple bug like this survive in your software for nearly a year now?

JJB7

I have the latest version of SQL Generator installed and this issue still exists I'm trying to clone a production database with masked data therefore referencing a source database to push to a destination database. The odd thing about this behaviour is the GUI will at least present the data from the source so it is able to handle the non-dbo location yet the script still fails because it isn't in dbo. I'm intending on working around this by putting dbo synonyms in the destination database so I'm not interfering with production but this isn't ideal.

Is there any progress on fixing this?

Rob C

Apologies for this. We now have a private build that should fix this problem. To obtain it, please email support@red-gate.com and copy the URL for this forum topic into the email.

Sorry for the inconvenience.