So... Die Exception hat keine InnerException. Der Vollständigkeit halber hier mal die Details der Ausnahme:

Fehlermeldung:
message: Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.

stacktrace: bei System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable1 pendingMigrations, String targetMigrationId, String lastMigrationId) bei System.Data.Entity.Migrations.DbMigrator.UpdateInternal(String targetMigration) bei System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase) bei System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration) bei System.Data.Entity.MigrateDatabaseToLatestVersion2.InitializeDatabase(TContext context)
bei System.Data.Entity.Internal.InternalContext.PerformInitializationAction(Action action)
bei System.Data.Entity.Internal.InternalContext.PerformDatabaseInitialization()
bei System.Data.Entity.Internal.RetryAction1.PerformAction(TInput input) bei System.Data.Entity.Internal.LazyInternalContext.InitializeDatabaseAction(Action1 action)
bei System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
bei System.Data.Entity.Internal.Linq.InternalSet1.Initialize() bei System.Data.Entity.Internal.Linq.InternalSet1.get_InternalContext()
bei System.Data.Entity.Infrastructure.DbQuery1.System.Linq.IQueryable.get_Provider() bei System.Linq.Queryable.Where[TSource](IQueryable1 source, Expression`1 predicate)

source: EntityFramework

Mittlerweile habe ich keine Idee mehr, wo ich noch ansetzen könnte.

Hallo Abt,

das Schema ist bei allen identisch. Alle greifen auf dieselbe Datenbank zu. Die Datenbank-Anmeldung ist an eine Active-Directory-Gruppe gekoppelt, in der die entsprechenden Benutzer Mitglied sind. Gegenwärtig verfüge ich nur über den entsprechenden Eintrag des Windows-Ereignisprotokolls. Ich werde mich mal um die InnerException bemühen...

Hallo,

in meiner Anwendung (basierend auf EF6 und NET4.5) verwende ich als Strategie Code-First mit Code-based Migration und MigrateDatabaseToLatestVersion als Initialisierer. Einer meiner Kunden berichtete mir nun kürzlich nach dem Einspielen eines Updates, dass beim Start eine AutomaticMigrationsDisabledException geworfen wird. Merkwürdigerweise aber nur auf 2 Arbeitsstationen. Andere Anwender haben dieses Problem nicht.

Um dem Ganzen auf die Schliche zu kommen, habe ich AutomaticMigrations aktiviert um EF ausführen zu lassen, was auch immer es ausführen möchte. Nachdem dies geschehen ist, habe ich den entsprechenden Eintrag aus der Tabelle "__MigrationHistory" genommen und aus der model-Spalte ein Entity Data Model (EDMX) generiert. Darin habe ich gesehen, dass das Entity Framework aus einer 1:1 - Beziehung (EDMX : Multiplicity="1") eine optionale Beziehung (EDMX : Multiplicity="0..1") machen will. Die Property meiner Klasse, auf welcher diese Beziehung beruht ist eine einfache GUID (nicht nullbar). Somit ergibt eine optionale Beziehung wie sie erstellt werden soll keinen sinn. Das merkwürdigste ist aber, dass das Problem lediglich auf 2 Arbeitsplätzen auftritt. Glücklicherweise sind dies die Arbeitsplätze der beiden Administratoren und werden somit auch nur zu administrativen zwecken genutzt. Dennoch muss das Problem gelöst werden. Hat jemand bereits ein ähnliches Problem gehabt oder eine Idee wo ich noch ansetzen könnte?

MfG Hurby

Erstmal Danke für eure schnellen und konstruktiven Antworten. Dass mir eine entsprechend große Abfrage nicht in die Tüte kommt war vielleicht etwas vorschnell. Wenn es tatsächlich keine anderen Lösungen gibt, welche sich mit überschaubarem Aufwand umsetzen lassen, werde ich diesen Lösungsansatz doch näher in Betracht ziehen. Zumal, wie ihr schon festgehalten habt, die Cleverness des SQL-Servers dort voll zur Geltung kommt.

Ich lasse den Thread mal noch offen. Vielleicht kommt ja doch noch Jemand mit einer völlig anderen Lösung um die Ecke.

Euch 3 wünsche ich auf jeden Fall erstmal ein schönes Wochenende

Hallo,

ich muss in einer Anwendung eine Recherche-Funktion programmieren. Diese sieht bis jetzt so aus, dass der Benutzer aus einer Liste von verfügbaren Datenfeldern mehrere auswählen kann. Zu jedem ausgewählten Datenfeld wird eine Vergleichsmethode und ein Vergleichswert angegeben.
Am Ende kommt also eine Liste von Konditionen heraus, welche durch jeden Datensatz zu erfüllen sind. Nun stehe ich vor dem Problem, diese Konditionen entsprechend zu prüfen. Aus allen Konditionen eine riesige (und dreckige) Abfrage zu basteln kommt mir nicht in die Tüte. Alle Datensätze einzulesen und dann im Programm auszuwerten halte ich aufgrund der Datenmenge auch eher für suboptimal. Ich bräuchte viel mehr eine Möglichkeit, die Konditionen in Abfragen umzuwandeln und nacheinander auszuführen. Wobei die erste den Inhalt der kompletten Tabelle auswertet und jede weitere nur das Ergebnis der vorherigen Abfrage verwenden sollte.

Ich weiß, dass es im SQL-Server sogenannte "Common Table Expressions" gibt, welche eine rekursive Abfrage erlauben. Allerdings müsste diese bei jedem Durchlauf die nächste Kondition verarbeiten. Leider weiß ich nicht, wie ich dieses Problem bewerkstelligen soll.

Hat Jemand eine zündende Idee (gerne auch in Kombination mit gespeicherten Prozeduren)? Oder vielleicht einen völlig anderen Ansatz?

Verstehe.

Dann bedanke ich mich trotzdem nochmal bei dir und den anderen beiden und schließe damit den Thread...

Wenn nun die Verlagerung der UI in die DLL unumgänglich ist, sind dann die 3 von mir genannten Schritte so korrekt? Falls nein, wie müsste der Ablauf in etwa aussehen?

So ist es, allerdings ruft die Cobol-Runtime die DLL nicht direkt auf, sondern bedient sich dazu einer C++/CLI-DLL, welche die C#-DLL wrappt. Aus (vorrangig) ästhetischen Gründen soll die Oberfläche auf WPF basieren.

Die C#-DLL ist allerdings keine Benutzersteuerelementbibliothek, sondern eine einfache DLL, welche WPF- XAML-Funktionalität besitzt. Demnach sind doch beim Einstieg noch keinerlei WPF-spezifischen Dinge (Nachrichtenschleife und UI-Thread) geladen, oder?

Okay. Da allerdings der Consumer der DLL ein Cobol-Programm hust ist, wird die UI in der DLL landen. Das Problem ist dass ich den initialen Appartement-State nicht kenne. Deswegen muss ich doch zwangsläufig einen neuen Thread nutzen um den State festzulegen, oder?

Du meinst also, dass die DLL lediglich die Validierungsfunktionalität bereitstellt und die UI in die aufrufende Anwendung verlegt werden soll?