Designer: Update model from database does not ask for the latest version of schema view


When trying to update model from the database with Entiy Designer the designer uses the overload of CreateStoreSchemaConnection that does not have version parameter. This overload results in always asking for v2 schema view while the latest version is v3. Since the v3 schema understands spatial types and TVFs and v2 schema don't the update model from the database will not work correctly for models that are using these features (not sure what "will not work correctly" means - can be a crash since the model may already have spatial types/TVFs or new TVFs will not be just present after updating the model from the database). In addition if the provider does not have v2 schemas but only v3 schemas (which is fine) update from the database will not work at all.

The bug is in the ModelBuilderEngine.cs file on line 376. Note that we already have the logic for probing versions and we use it for generating model from the database - see GetEntityConnection method in the DatabaseMetadataQueryTool.cs ln. 151
Closed Apr 23, 2013 at 11:22 PM by moozzyk
See comments.


RoMiller wrote May 8, 2012 at 4:46 PM

Edited by Lawrence Jones

I've looked into this and the code at line 376 of ModelBuilderEngine is used by Update Model but only at the very beginning of the wizard where it's deciding which page to show first. After this the other code in DatabaseMetadataQueryTool.cs is used.

The purpose of the original call is to decide whether to show the "Choose Your Data Connection" wizard page (page 2) or to skip it and go directly to the "Choose Your Database Objects" page (page 3) which it does by attempting to open a DB connection using the existing connection string.

The worst that could happen here is that the provider does not support V2 and so incorrectly says that it cannot create a DB connection using the existing connection string (by throwing an exception) in which case the wizard will start on page 2 instead of page 3. However from then on Update Model will use the correct call and the runtime will receive the CreateStoreSchemaConnection() call with the version parameter.

This greatly reduces the priority IMO so have updated the Pri/Sev and am returning to triage.

RoMiller wrote Jan 23, 2013 at 10:34 PM

EF Team Triage: Check if we fixed this in VS 2012

moozzyk wrote Apr 23, 2013 at 11:21 PM

This was fixed when we removed dependency on SDED for reverse engineering db. We no longer have the overload that blindly uses v2. Now we have overloads - one that does not take the version but probes and uses the latest and one that takes the version.