Devart Forums

We're using dotConnect for Oracle 5.35.79.0 to access two views and a table via an Entity Framework model. We're connecting to Oracle 11g in test and 10g in production. Test is working great.

We copied the views and table to a production schema and changed the connectionstring for the entity model to the userID and password of the production schema owner. When we fired up the production application, we got "ORA-00942: table or view does not exist" errors when attempting to access any of the views or table. The production connection string credentials were good enough to login to Oracle, but not good enough to see the views and table.

We then changed the production Entity Model connection string in the web.config file to point back to the test database. The production instance was able to access the test db objects without a problem.

My Oracle guy insists that the production string credentials are that of the production schema owner and therefore should be able to see the views and table. He is pointing his figure at dotConnect. If we were using Sql Server, I'd turn on the profiler and find out what is really going on. My Oracle guy says that Oracle doesn't have a similar profiler.

Does DevArt provide any way to see the conversation between dotConnect and Oracle? Any ideas? Help!

You can add DBMonitor to your application to watch the queries sent to database.
However, in your case the situation seems to be simple.
I recommend you to edit the model file and remove the "Schema="" attribute.
In case of .edmx use any XML Editor you like, .edml file has the Store model that can be edited in design time.

Thank you for saving my bacon, Andrey.

In addition to inserting Schema="xxx" properties in the .edmx file, dotConnect for Oracle also qualified the view names with the schema name in the sql statements generated to read the views. After removing the schema="xxx" properties and the schema qualifiers from the view names in the .edmx sql, everything worked as expected.

I suppose that the schema needs to be included in cases where views from multiple schemas are represented in the same Entity Model.

You are correct, the reason for schema name adding is cross-schema support.