locked
How to clear than instantiate dbContext? RRS feed

  • Question

  • User-29703693 posted

    I'm doing error handling and I have the following code that I'm purposefully generating an exception:

    _db.t_Application.Update(application);  
    _db.SaveChanges(); // string or binary would be truncated error

    My app then jumps to the Error method where I'm trying to save to a log file:

    t_Log log = new t_Log();
     _db.t_Log.Add(log);
    _db.SaveChanges(); // give the same error, since it's still trying to update t_Application

    However, it's still trying to run the update on the t_Application table and gives the same error. 

    Do I need to dispose the dbcontext and if so how do instantiate it again?  I've been using dependency injection where I register dbcontext in startup.cs so I can't just do DbContext _db = new DbContext() because it requires the options parameter.  I'm not sure what to pass there and if Disposing is even the best route.

    Thanks in advance.

    Friday, October 25, 2019 8:27 PM

Answers

  • User-29703693 posted

    ^ Thanks.  I may look to use ADO.NET instead.

    I figured out the parameter should be DbContextOptionBuilder options so the below code works. It feels like a bit of a work around but is still pretty simple

    var optionsBuilder = new DbContextOptionsBuilder<DbContext>();
    optionsBuilder.UseSqlServer(_config.GetConnectionString("ConnectionString"));
    DbContext db = new DbContext(optionsBuilder.Options);
    t_Log log = new t_Log();
    db.t_Log.Add(log);
    db.SaveChanges();

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, October 25, 2019 9:09 PM

All replies

  • User1120430333 posted

    It seems to me that you don't have exception handling set up right. And IMO, the logging of any error to the log file table sitting in the database should be using straight-up ADO.NET and database command objects with inline T-SQL and a non EF connection, a different and separate connection,  and let the whole program just terminate after logging.

    You're trying to use EF again when EF through the exception and expecting to somehow recover Dbcontext?  That's not likely.

    Friday, October 25, 2019 8:46 PM
  • User-29703693 posted

    ^ Thanks.  I may look to use ADO.NET instead.

    I figured out the parameter should be DbContextOptionBuilder options so the below code works. It feels like a bit of a work around but is still pretty simple

    var optionsBuilder = new DbContextOptionsBuilder<DbContext>();
    optionsBuilder.UseSqlServer(_config.GetConnectionString("ConnectionString"));
    DbContext db = new DbContext(optionsBuilder.Options);
    t_Log log = new t_Log();
    db.t_Log.Add(log);
    db.SaveChanges();

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, October 25, 2019 9:09 PM
  • User1120430333 posted

    ^ Thanks.  I may look to use ADO.NET instead.

    I figured out the parameter should be DbContextOptionBuilder options so the below code works. It feels like a bit of a work around but is still pretty simple

    var optionsBuilder = new DbContextOptionsBuilder<DbContext>();
    optionsBuilder.UseSqlServer(_config.GetConnectionString("ConnectionString"));
    DbContext db = new DbContext(optionsBuilder.Options);
    t_Log log = new t_Log();
    db.t_Log.Add(log);
    db.SaveChanges();

    If you were using a logging framework like Serilog, Nlog, Log4net or one of the others, they have their own connection to the database using their custom table, and they would not be depended upon an ORM like EF's connection. 

    Saturday, October 26, 2019 3:45 PM