Fixed ,thanks
the DB migrator now see the db and created the DB , but with only history table, I am trying to create migration script but says cannot fine this dbcontext :
dotnet ef migrations add Init_Audit_Logging
--context Volo.Abp.AuditLogging.EntityFrameworkCore.AbpAuditLoggingDbContext
No DbContext named 'AbpAuditLoggingDbContext' was found.
under which project should that script be run and is there another way to generate the migration script ?
Yes it is MSSQL , but based on previous comments, I am just using builtin AbpAuditLoggingDbContext do I really need to create a seperate module and DbContextFactory ?
followed all the above, yet when running DB Migrator no new DB is created, also when I run migration script from cmd I get this error :
dotnet ef migrations add "Init_Audit_Logging" --context AbpAuditLoggingDbContext Build started... Build succeeded. No DbContext named 'AbpAuditLoggingDbContext' was found.
But I see no relationship between connectionstring and auditing DB context, how to set the connection string name to auditing DB context or there is a default value for audit db context connectionstring
I get syntax error on this line : database.MappedConnections.Add(typeof(AbpAuditLoggingDbContext));
because Add method accept string , but we are passing type
Do I need to create another DBMigrator project for auditing DB or you recommended using one DB Migrator for both prod and auditing databases , any example ?
We are planning to enable audit on our app , but we want to use a separate MSSQL DB to store the audit data. What is the best recommended way to setup a new separate database , and do we need to implement a custom IAuditingStore store just because we use a different database ? there is a way to pass the connection string of the other database ?
thanks
We have a case when we want to add extra logic whenever Update ABP user from admin area and press save . But currently seem like this is a built-in method that's not possible to edit. PUT api/identity/users/{id}
We know there is there already event on updated ABP user but it get called a lot. And we cannot use it unless there is a way to compare old data of user entity with the new data so we can take action based on that such as comparing if Surname was changed from old one to new one .
Currently if transaction is rolled back , the job create is not rolled back .
