I am recently started working on Microsoft Sync framework 2.1 based project, which already developed, requirement is simple to sync db(server to client and client to server), but i am getting very frequent error stating blah_blah_selectchanges already exist(procedure), once i will delete all mentioned procedure it will work fine.. then again when i am trying with another machine this error comes again.. Now i am not getting a idea how to overcome with this error... I did some research and found additional tables(under sync db) created by the provisioning process: Products_Tracking, schema_info, scope_config, and scope_info. There are also other database objects such as triggers and stored procedures created by the provisioning process. I have one doubt if additional table/Procedure/Triggers is already exist on sync schema why it is creating again..
check how you're provisioning. Are you checking if the scope exists already? if there are existing scopes for the table and you want to add a new scope, you should specify SetCreateProceduresForAdditionalScopeDefault.
Related
We use MSSQL for our C# .NET Framework 4.8 Application using Entity Framework for database related activities.
But on our production environment the SQL server has the Securable: View any database on Deny.
The database for the application exists but Entity Framework cannot see the database and tries to create it, this results in the CREATE DATABASE permission denied in database 'master' error.
I am using CreateDatabaseIfNotExists and MigrateDatabaseToLatestVersion in my Application_Start().
Now the issue (I think) lies with CreateDatabaseIfNotExists.
For the first run we give the db user enough rights to create and fill the database, it does this without problem.
But after the initial setup we remove those rights and the issue starts.
It tries to create the database, But it already exists.
And I am hoping there is a way to have both Automatic database creation/migration, and the View any database on deny securable.
Does anyone have a idea on how to solve this issue?
Is there some sort of option I could enable to stop this behaviour?
You should "wire in" IHostingEnvironment and make sure you run
CreateDatabaseIfNotExists and MigrateDatabaseToLatestVersion
only in certain environments.
===========
For DotNet-Core (NON asp.net-core) apps.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.internal.hostingenvironment?view=dotnet-plat-ext-7.0
for asp.net-core.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.hosting.iwebhostenvironment?view=aspnetcore-6.0
....
Then you will use (probably an existing)
"Is" method:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.hosting.hostingenvironmentextensions.isdevelopment?view=aspnetcore-7.0
IsDevelopment
IsProduction
IsStaging
or you have the ability to "add your own environment".. with
IsEnvironment(string)
I would NEVER leave to "auto-voodoo" what might happen to the production database.
You can see this approach:
https://stackoverflow.com/a/60399887/214977
I'm writing a WPF application.
Trying to use the normal method of getting a connection returns an error similar to: "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."
ACE.OLEDB has never been installed on this machine so this error makes sense.
I'm trying to create this application in a way so that our users won't need to contact IT to have the application installed. Getting IT involved is a no go situation and the project will be abandoned.
Another team has an Access database (accdb) that I want my application to extract information (only read, no insert or update). I talked to the team and they won't convert this database back to an earlier version (mdb).
After my research I assume that installing ACE.OLEDB without using Admin privileges is impossible. Because of this and my application requirement of not requiring admin privileges I need to start looking for "Mutant"/Dirty solutions that don't involve ACE.OLEDB.
I tried using power-shell but I'm getting the same problems as I had with C# (requires IT to install ACE.OLEDB).
I have two potential solutions. One write a VBA script that opens up the database and dumps a query result into a file. My C# application would call this VB script and then parse the created file.
The second option is to create a new Access process using Process.Start(fullFilePath) and somehow pass the command to execute a query and somehow pass the results back to the executing application (either via a method return or first to a file).
How would you get the data out?
Is there a way for C# to duplicate the DB file and convert it from (accdb -> mdb)?
This is the second question I ask that is very similar.
C# Connecting to Access DB with no install
The difference between the two (to prevent this is a duplicate question) is that in the previous question I was looking for ways to install ACE.OLEDB without admin privileges while here I'm just looking for any other work around.
Found a workaround. It uses Microsoft.Office.Interop.Access found in NuGet.
var accApp = new Microsoft.Office.Interop.Access.Application();
accApp.OpenCurrentDatabase(#tests.DatabasePath);
Microsoft.Office.Interop.Access.Dao.Database cdb = accApp.CurrentDb();
Microsoft.Office.Interop.Access.Dao.Recordset rst =
cdb.OpenRecordset(
"SELECT * FROM Users",
Microsoft.Office.Interop.Access.Dao.RecordsetTypeEnum.dbOpenSnapshot);
while (!rst.EOF)
{
Console.WriteLine(rst.Fields["username"].Value);
rst.MoveNext();
}
rst.Close();
accApp.CloseCurrentDatabase();
accApp.Quit();
So far what I've tried is to verify that my certificates for SSL are correct and through command line (Using psql) and through a console application (Npgsql) I'm able to reach the database with SSL enabled (No password needed). This is working.. My problem starts with the SSL.
The application I'm working on has working Data Access to Postgre using Entity Framework 6 on non-SSL. However when I try to update the string to use SSL, I need to find a place to pass in the client-certificates. I've looked at different places. Right now, I have changed the DbContext() constructor to use base(DbConnection,bool) so that I can pass in a connection that has been provided the callback method. However, I get this error:
The context cannot be used while the model is being created. This
exception may be thrown if the context is used inside the
OnModelCreating method or if the same context instance is accessed by
multiple threads concurrently. Note that instance members of DbContext
and related classes are not guaranteed to be thread safe.
I've tried to apply different fixes from SO to solve this error, but to no avail.
Anything helps!
I'm having problems publishing my MVC project.
I got the error "The model backing the 'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).", that was solved with the help of automigrations.
I published my project via ftp on the another machine, then added some changes on the model`s structure, run it on my computer, it launced succesfull and published again on the same another machine. When I tryed to run it there, an error occurred - "The model backing the 'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269)."
I'm using IIS7 on Windows 7.
To update database on another Db server you could make this way:
Configure connection string to use new server
Run Update-database command from package manager console, in some cases you will need to use -force flag. But be careful this could delete some your data. Also this command has - ConnectionStringName parameter this could help you to make updates.
This is a very bad approach and I don't recommend update database this way.
I would recommend you set up Initialzier for your context. I usually use MigrateDatabaseToLatestVersion and after changing your model you will need to add new migration, using Add-migration command.
To set up it use this command in application start method:
Database.SetInitializer<ApplicationDbContext>(new MigrateDatabaseToLatestVersion<ApplicationDbContext>());
You must update your database after changing the model. Another machine and your computer use the same database? If not you must update this database.
I've got a SQL Server mirroring set up with a primary, secondary and witness to provide automatic failover for my application. I've been experimenting with using the CommitFailureHandler class but I've run into a problem when using it in a specific scenario:
In the connection string the database server that is currently the
Mirror must specified as the Data Source and the Principal must be
specified as the Failover Partner.
The application must have migrations to perform against the database
The __TransactionHistory table must not exist
If any of those three conditions are not present then it works without problems.
When this situation does occur then a SqlException is thrown saying that Login Failed for the given user. I also the following messages in the SQL Server event log (on the Mirror instance):
Login failed for user 'myUser'. Reason: Failed to open the explicitly specified database 'myDatabase'.
Login failed for user 'myUser'. Reason: Password did not match that for the login provided.
For the record, the login and password are correct and work fine when any one of the three conditions are not true.
Here is the line where I set the transaction handler in my Database Configuration class:
SetTransactionHandler(SqlProviderServices.ProviderInvariantName, () => new CommitFailureHandler());
What's going on?
So I found this issue on the entity framework issues tracker: https://entityframework.codeplex.com/workitem/2050
It appears that there is a bug in EF 6.1 where the credentials would be stripped out of the connection string before the __TransactionHistory table could be created in the circumstances given in the question (it also manifested in SQL Azure).
The bug has been fixed in the latest beta of EF (6.1.1-beta1).