Laden...

EFCore Daten werden nicht in DB geschrieben

Erstellt von GeneVorph vor 3 Jahren Letzter Beitrag vor 3 Jahren 441 Views
G
GeneVorph Themenstarter:in
180 Beiträge seit 2015
vor 3 Jahren
EFCore Daten werden nicht in DB geschrieben

Verwendetes Datenbanksystem: EntityFrameworkCore 5 w/ SQLite

Hallo,
ich habe mir ein Test-Projekt (Konsolenanwendung) mit einer Test-Datenbank angelegt. Das Problem besteht darin, dass


using (var context = new DataBaseContext())
{
    context.MidiItems.Add(mI);
    context.SaveChanges();
}

NICHT dazu führt, dass der Wert in die Datenbank geschrieben wird.

Hier das Model


public class MidiItem
{
public int ItemID {get;set;}
public string MyValue {get;set;}
}

Mein DataBaseContext:


public class DataBaseContext: DbContext
    {
        public DbSet<MidiItem> MidiItems{ get; set; }
      
        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlite(connectionString: "FileName =./Test_DataBase00.sqlite");
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.ApplyConfiguration(new MidiItemEntityConfiguration());
         }
    }

Meine MidiItemEntityConfiguration


public class MidiItemEntityConfiguration : IEntityTypeConfiguration<MidiItem>
    {
        public void Configure(EntityTypeBuilder<MidiItem> builder)
        {
            builder.HasKey(s => s.ItemID);         
        }
    }

Und mein Program.cs-Code


static void Main(string[] args)
  {
       // var context = new DataBaseContext(); --> mein erster Versuch...
       using (var context = new DataBaseContext())
       {
           context.DataBase.EnsureCreated();
       }

       MidiItem mI = new MidiItem();
       mI.MyValue = "Test";

     // context.MidiItems.Add(mI);
     // context.SaveChanges(); --> erster Versuch....
      using (var context = new DataBaseContext())
      {
           context.MidiItems.Add(mI);
           context.SaveChanges();    
      }
       
  }

Mehr Code habe ich bisher nicht.

Der Code läuft ohne Fehler durch - wenn ich einen Breakpoint setze, kann ich sehen, dass der Eintrag unter context-->local-->MidiItems auftaucht.
Leider landet der Wert nicht in der Datenbank.
Ich kann zwar die Struktur in SQLite-Studio sehen (ItemID | MyValue), aber das item wird nicht hinzugefügt.

Ich stehe gerade vollkommen auf dem Schlauch - in meinen wpf-Projekten habe ich das im Prinzip auch nicht anders gelöst - warum sollte es bei einer Konsolenanwendung nicht klappen.

Wenn ich Migrations anwende, sehe ich, dass die Struktur der Datenbank so wiedergespiegelt wird, wie sie auch intendiert ist. Habe ich evtl. eine Library nicht implementiert? Bisher:

  • Microsoft.EntityFrameworkCore.SQLite 5.0.3
  • Microsoft.EntityFrameworkCore.SQLite.Design 1.1.6
  • Microsoft.EntityFrameworkCore.Tools 5.0.3

Gruß
vorph

W
955 Beiträge seit 2010
vor 3 Jahren

* Exception handling korrekt implementieren
* Logging verwenden, damit der Provider sagen kann was nicht passt

G
GeneVorph Themenstarter:in
180 Beiträge seit 2015
vor 3 Jahren

Yes - ich hatte schon befürchtet, dass es nichts Offensichtliches ist^^

@Exception handling --> setzt das nicht voraus, dass überhaupt eine Exception geworfen wird?

Das mit dem Logging - keine Ahnung was das ist oder was es bedeutet; meintest du sowas Logging in .NET Core and ASP.NET Core

Hinweis von Abt vor 3 Jahren

Die BBCodes richtig auszufüllen is echt nich so schwer 😃
Habs korrigiert.,

2.079 Beiträge seit 2012
vor 3 Jahren

Dein Link funktioniert nicht.

Und er meint z.B. das hier beschriebene Logging: Logging
Kurz: Ereignisse jeder Art irgendwo hin schreiben.

EFCore unterstützt einige Möglichkeiten zur Konfiguration vom Logging:

Überblick über Protokollierung und Abfangfunktionen: EF Core
Ich persönlich würde das Logging-Framework von Microsoft verwenden:
Verwenden von Microsoft. Extensions. Logging-EF Core
Das wird auch in ASP.NET Core verwendet und kann mit so jedem (mir bekannten) größeren Community-Logging-Framework zusammen arbeiten.

Und dann kann EFCore noch Warnungen und Fehler anders behandeln:
DbContextOptionsBuilder.ConfigureWarnings Method (Microsoft.EntityFrameworkCore)
Ob das für dich relevant ist, weiß ich nicht, aber man sollte es zumindest mal gesehen haben.

16.827 Beiträge seit 2008
vor 3 Jahren

Seit wann unterstützt der Connection String den führenden Punkt?


optionsBuilder.UseSqlite(connectionString: "FileName =./Test_DataBase00.sqlite");

Und der Space wird meines wissens auch nicht gemocht.

G
GeneVorph Themenstarter:in
180 Beiträge seit 2015
vor 3 Jahren

Sodale - vielen Dankf für die Hilfe(n) - ich habe mich einige Zeit jetzt mit Logging beschäftigt; mit Sicherheit nicht umsonst. Ich kapier zwar immer noch nicht alles, aber so hab ich wenigstens den Fehler schnell gefunden.

Die Lösung ist mal wieder banal - auch wenn ich sie mir nicht erklären kann:

  • soweit ich weiß, wird bei der von mir verwendeten Schreibweise "FileName =./Test_DataBase00.sqlite" die Datenbank immer relativ zum Projektordner erstellt, und zwar unter Projekt-->bin-->Debug-->netcoreapp3.1

Dort fand ich auch bei mir die Test_DataBase00.sqlite

Nur, dass sie bei mir leer war, obwohl scheinbar soweit alles in Ordnung war. War es auch. Allerdings wurde eine identische Datei unter 'Projekt' erstellt. Und diese enthielt alle Daten.

Ich habe die Datenbank jetzt schon umbenannt, gelöscht, ausgetauscht - egal: nach der ersten Migration (erst nach 'update-database') habe ich die Datenbankdatei einmal unter Debug, und einmal direkt im primären Ordner.

Soll das so sein? Ich hatte bisher Datenbanken in der Konstellation EFcore und sqlite nur in Verbindung mit wpf-Projekten genutzt. Sollte das bei einer Konsolen-App anders sein? Wohl kaum, oder?

Jedenfalls - jetzt, da ich mit SQLite-Studio die richtige Datei öffne, klappt auch alles.

Seit wann unterstützt der Connection String den führenden Punkt?

optionsBuilder.UseSqlite(connectionString: "FileName =./Test_DataBase00.sqlite");

Und der Space wird meines wissens auch nicht gemocht.

Also, bei meinen wpf-Projekten hatte ich das immer so gemacht, seit ich das mal in Zusammenhang mit einem wpf-Tutorial so gesehen hatte - da gab es bislang keinen Stress. Es stünde natürlich zu vermuten, dass hier ein Grund für den Fehler liegt - aber das wäre schon strange, wenn die Art des Projekts (Konsole vs. wpf) Auswirkungen auf die Erstellung der DB haben sollte...
Wie gesagt, ich kenne keine andere Form: wie wäre es denn besser, wenn man möchte, dass die DB sich immer in einem Ordner relativ zur App befindet?

Ansonsten nochmal vielen Dank für den Logging Hinweis - wieder was gelernt 🙂

16.827 Beiträge seit 2008
vor 3 Jahren

FileName geht immer von einer relativen Pfadangabe aus, wenn man keinen vollständigen Pfad angibt.

DB sich immer in einem Ordner relativ zur App befindet?

Nicht unbedingt so eine gute Idee.

Normalerweise befinden sich Applikationen in einem Ordner, in dem ein normaler Benutzer und damit die Applikation zur Laufzeit keine Schreibrechte hat.

Daher gibt es unter Windows extra Ordner für sowas, die man direkt in .NET dafür ansprechen kann.
Environment.SpecialFolder Enumeration (System)