CapableObjects forum



Problems using database created in older version of ECO

Posted By Daniel Wikholm 2013-11-28 15:35:17
Add to Favorites0
Author Message
Daniel Wikholm
 Posted 2013-11-28 15:35:17
Supreme Being

Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)

Group: Forum Members
Last Active: 2016-05-13 18:04:23
Posts: 19, Visits: 180
I have a class model in Eco4 (3583) for Delphi2007.
I have manually recreated the same model in Eco6/7 (6868) for VS2012. (I know there are other ways.)
I have databases, in the same instance of SQL Server 2008 R2, created from both environments.

If I set the sqlConnection of the PMP in the VS solution to the "new" database and clicks Evolve Schema I get, as expected, "No action needed".
If, however, I set it to the "old" database the evolver gives me a bunch of errors.

It says, for example, "Failed to read discriminators from database, required for classes: HwkFunktionHwkFunktionHwkPartStrakHwkPartStrak".
That "class" is a link table representing a *-* between the classes HwkFunktion and HwkPartStrak.

It also says "Duplicate classes (HwkPerifer and HwkPeriferNod) in type table for discriminator 46".
HwkPerifer is an older name for the class nowadays called HwkPeriferNod. That class has FormerNames set in both models.

The table names in both databases are, character by character, identical (although the "old" database does contain one eco-unrelated table).
The ECO_ORMAPPING is empty in both databases. ECOModelRoot is childmapped in both databases.
The ECO_TABLES contains, character by character, exactly the same tablenames (unsorted they, naturally, appears in different orders).
The ECO_TYPE column of the ECO_TYPE tables differs, but the classnames are identical.
In the old database there are a few ECO_TYPE entries no longer in use (old names for three classes, and ECOModelRoot).

Any clues to why I still get these errors?
Scott Price
 Posted 2013-12-18 13:18:58
Supreme Being

Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)Supreme Being - (17 865 reputation)

Group: Forum Members
Last Active: 2014-02-06 08:37:13
Posts: 206, Visits: 841
Have you tried Reverse Engineering the model of the old database into ECO using the import process?

It might be that the XML in the database for the old mapping and the new mapping don't bare close relation, as a lot may have changed in that time. I would suggest exporting the data from the mapping field in the old database, and examining the XML. This might need a little alteration, but you can then use that XML as the mapping info the application can use.

I'm unsure if Hans has created an example of reverse engineering an older form ECO database, or using the XML mapping files instead of the one stored in the database.
HansKarlsen
 Posted 2013-12-18 17:51:11
Supreme Being

Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)Supreme Being - (102 786 reputation)

Group: Administrators
Last Active: 2016-05-11 20:56:01
Posts: 608, Visits: 3 230
ECO_ORMAPPING is empty... So you have another mappingprovider - like a FileMappingProvider? The Mapping is what ECO use to find the change needs... It reads the old/existing ORMAPPING via the OldMappingProvider, and compares this with what it gets from the NewMappingProvider.

The default and standard is to save the existing/current/old OR mappping in the db in the ECO_ORMAPPING table.
Daniel Wikholm
 Posted 2014-01-07 15:50:49
Supreme Being

Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)Supreme Being - (4 405 reputation)

Group: Forum Members
Last Active: 2016-05-13 18:04:23
Posts: 19, Visits: 180
Right before Christmas, I solved this. What I read as two diffrent error messages ("Failed to read discriminators..." and "Duplicate classes ... in type table") turned out to be a single long-ish one.

Eco "Failed to read discriminators..." because of the "Duplicate classes ... in type table". ECO III and IV apparently kept entries for renamed classes in ECO_TYPE, while current ECO appears not to like that. Removing the entries for the depecated table names was sufficient to solve "both" problems. Thus, for now, problem solved, but thanks a lot for the assistance.

As a bit of background info, the PersistenceMapperProvider contains a SqlConnection, a PersistenceMapperSqlServer, a SyncHandler (unused, I think) and a defaultORMappingBuilder (to childmap EcoModelRoot). Eco has generated the DB schema itself and I can only presume it, in this scenario, only needs what's stored in ECO_TABLES, ECO_TYPE and in the model. I know it's standard to use ECO_ORMAPPING. Since our application will have to work with old ECO databases, to which I have no direct access, and in which ECO_ORMAPPING is empty, I can't rely directly on that.

Similar Topics

Expand / Collapse

Reading This Topic

Expand / Collapse

Back To Top