Devart oracle provider error happens when -connectionStringName is added

[John Liu]

If the connectionStringName is named by default (long or short name of the implemented DbContext name), migrations up/down work fine. when it is not named that way and -connectionStringName is specified, an oracle object name too long error comes back. that was taken care with the following code
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.CodeFirstOptions.ColumnTypeCasingConventionCompatibility = true;
config.CodeFirstOptions.TruncateLongDefaultNames = true;
config.Workarounds.IgnoreDboSchemaName = true;
config.Workarounds.DisableQuoting = false;
I'm not sure why the error comes back?
thanks
JL


PM> update-database -targetmigration:0 -verbose -connectionStringName:CwDbContext1
Using StartUp project 'Cityworks.DataAccess'.
Using NuGet project 'Cityworks.DataAccess'.
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
Target database is: '' (DataSource: 192.168.20.86, Provider: Devart.Data.Oracle, Origin: Explicit).
Reverting migrations: [201302262321534_V20130000, 201302221703117_V20120100].
Reverting explicit migration: 201302262321534_V20130000.
System.InvalidOperationException: Foreign key name 'FK_TASK_RESULT_INSERT_TASK_INSERT_TASK_ID' in table AZTECA.TASK_RESULT_INSERT is too long (41 characters). An identifier with more than 30 characters was specified.
at Devart.Common.Entity.Migrations.f.a(String A_0, String A_1, String A_2)
at Devart.Common.Entity.Migrations.f.a(dl A_0)
at Devart.Common.Entity.dl.a(ba A_0)
at Devart.Common.Entity.Migrations.e.a(IEnumerable`1 A_0)
at Devart.Common.Entity.Migrations.c.a(IEnumerable`1 A_0, String A_1)
at Devart.Data.Oracle.Entity.Migrations.OracleEntityMigrationSqlGenerator.Generate(IEnumerable`1 migrationOperations, String providerManifestToken)
at System.Data.Entity.Migrations.DbMigrator.ExecuteOperations(String migrationId, XDocument targetModel, IEnumerable`1 operations, Boolean downgrading, Boolean auto)
at System.Data.Entity.Migrations.DbMigrator.RevertMigration(String migrationId, DbMigration migration, XDocument sourceModel, XDocument targetModel)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.RevertMigration(String migrationId, DbMigration migration, XDocument soureModel, XDocument targetModel)
at System.Data.Entity.Migrations.DbMigrator.Downgrade(IEnumerable`1 pendingMigrations)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.Downgrade(IEnumerable`1 pendingMigrations)
at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update(String targetMigration)
at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.RunCore()
at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.Run()
Foreign key name 'FK_TASK_RESULT_INSERT_TASK_INSERT_TASK_ID' in table AZTECA.TASK_RESULT_INSERT is too long (41 characters). An identifier with more than 30 characters was specified.

[John Liu]

I'm using devart.data.oracle 7.5.164.6 with EF6 Alpha 2. even if I keep my connectionStringName with the default convention. If I still specify -connectionStringName in PM or migrate.exe, The Ids generated for those object name longer than 30 are different from those genereated without specifying -connectionStringName. Is this a bug? this is a problem for our command line deployment for people to manager hundreds of databases

PM> update-database -verbose -connectionStringName:cwdbcontext
or
migrate.exe cwdbcontext.dll /startupConfigurationFile=%ConfigFile% /ConnectionStringName:%ConnectionName% /verbose

[Shalex]

Code: Select all

var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.CodeFirstOptions.ColumnTypeCasingConventionCompatibility = true;
config.CodeFirstOptions.TruncateLongDefaultNames = true;
config.Workarounds.IgnoreDboSchemaName = true;
config.Workarounds.DisableQuoting = false;

Please put this code in a static constructor of your DbContext descendant. Does it help?

[John Liu]

Thanks for your reply. I already have those code in my constructor. that doesn't help.
with -connectionStringName added in PM or in Migrate.exe, The ids generated for those names with more than 30 chars are different from those without the connectionStringName specification.
JL

[Shalex]

We have just sent to your e-mail a test project with the instructions. Please confirm that you received it.