Specifying a schema in the connection string does not filter.

[[email protected]]

Even when a schema is specified in the connection string of a Data Connection, all tables/views/etc from all schemas are shown in the Visual Studio Query Designer.

Steps to reproduce
1) From Visual Studio, create a new Data Connection to a database that has multiple schemas. In the connection string, specify a schema.
2) From the new Data Connection, create a new query.
3) The Query Designer will show all tables/views/etc... not just the ones from the schema in the connection string.

[Alexey.mdr]

Well, actually it's not a bug.
Issuing our products, we strive for achieving standard approach to data access solutions.
Microsoft suggested this way of table representations and we follow it.
So it would be clear and easy for every developer to get started with development of a new application linked to a different server.

[[email protected]]

Oh, okay. Well, it makes the provider very very slow when there are many many schemas in a database. It takes about 30 seconds for a query tab to show up on my many schema database as opposed to less than a second on an empty database. Then after the 30 second open time, when you switch query tabs, it takes about 10 seconds each time.

[Alexey.mdr]

I see... Sounds terrible.
What server do you use?
What type of LAN do you have?
It should not take so much time.
Probably something is slowing it down?

[[email protected]]

The server is Postgresql 7.3.
The lan is gigabit.

I think it's just loading a LOT of information. ~ 50 schemas times ~ 200 tables = 10,000 tables. It adds up quick. That's why a schema filter is nice.

[Alexey.mdr]

The problem is in DDEX.
This is a subsystem of Visual Studio that uses metadata.
It makes a huge amount of queries to the database instead of a large one.
When it's done with tables the same happens to the columns.

The same problem arises with parameters in a stored procedure.