Devart Forums

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.

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

John Liu wrote:

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?

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

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