Each time when i modify a oracle stored proc,i need to restart the was server to pick up the stored proc changes.
Is there any settings which can be used to reload the same in production env.
You may try to start your server in debugging mode and then , after changing your stored proc, clean build your project directory. But it is always advisable to not to use debug mode in Production Env.. If your stored proc is changing frequently, then you should change your stored proc to more dynamic one.
Related
I've built and installed the "apoc" procedures according to the github page (The apoc-1.0.0-SNAPSHOT.jar file was copied into the plugins directory after the suerver was stopped, and then I started the server again) but when I try to call any of the procedures, I get an error message.
ex:
$ call apoc.help('search') ;
"There is no procedure with the name apoc.help registered for this
database instance. Please ensure you've spelled the procedure name
correctly and that the procedure is properly deployed."
I have come across the issue on both MacOs and Windows installations. I'm running Neo4j 3.0.0 as a server (locally on port 7474).
Have I missed any of the settings?
Thanks,
Babak.
I had to manually add this line to the .neo4j.conf file:
dbms.directories.plugins=/Applications/Neo4j\ Community\ Edition.app/Contents/Resources/app/plugins
(assuming that's where you dropped the APOC jar) and then restart the server.
(It's a little confusing as there's an option in the management app to configure this path, but it seems not actually to enable plug-ins on the server.)
For Windows users it should look like this:
dbms.directories.plugins=c:/Program\ Files/Neo4j\ CE\ 3.0.0/plugins
Assuming You have Neo4j installed at Neo4j CE 3.0.0. The import
Now (2023) the procedure seems to be different.
There are potentially two files needed to run APOC (https://community.neo4j.com/t5/neo4j-graph-platform/unable-to-see-some-apoc-load-functions/m-p/64154)
Some functions may be disabled by default and need to be enabled in the relevant database config e.g., dbms.security.procedures.allowlist=apoc.coll.,apoc.load.,apoc.periodic.*
Consider turning it on and after use off again for security.
How to re-create the database using EF6?
I have tried both of following post but, i don't know why its not working and getting same error.
How do I generate an EF6 database with migrations enabled, without using update-database?
Migrations is enabled for context ''but the database does not exist or contains no mapped tables
I have already published my sample on the web server. I am using Sql Server 2012 Express DBMS.
When i have created my application and published it on web server it was working fine. It has created database automatically. After that i have made some changes in ApplicationDBContext and added some properties in IdentityModes(ApplicationUser). Then I have migrated database on my Local IIS Express and it was working fine. Then I have tried to publish my sample again on web server but, this time it shows an error.
Migrations is enabled for context 'ApplicationDbContext' but the database does
not exist or contains no mapped tables. Use Migrations to create the database
and its tables, for example by running the 'Update-Database' command from the
Package Manager Console.
I have deleted the database on web server and tried again. but, still i am facing same error. Now, there is an empty database without table.
Application is creating database on User Registration.
I have also read this post and tried to call dbContext.Database.Initialize(true); and ((IObjectContextAdapter)myContext).ObjectContext.CreateDatabase() method but, still its not working.
First, automatic migrations are nice for development but it's a hugely bad idea to rely on them in production. Second, at some point you turned off automatic migrations, which is why your production database is no longer having tables created in it.
Go ahead and leave automatic migrations off; even in development it's better to know exactly what changes you're making to your database by generating a migration, seeing the code that will be executed, and only then running Update-Database to apply those changes.
You have a number of choices in terms of getting schema updates into production, but they all boil down to roughly the same procedure.
Generate a new migration against your local database.
If you want to update your production database via SQL, run Update-Database -Script. This will generate a SQL file with the code to run on the database to migrate the schema. Hand this off to your DBA if you have one or review the SQL code yourself and then apply it manually to your database via Management Studio.
Run Update-Database. This time without -Script to make the changes to your local database schema.
If you didn't generate the SQL file in step 2, view your local database in SQL Server Object Explorer in Visual Studio. Right-click on the local database there and choose, "Schema Compare...". Follow the wizard to compare with your production database. In the end, you can either generate a SQL file with the necessary changes that need to be made (which again, you'd hand off to your DBA if you have one), or you can migrate to production directly from Visual Studio. However, this is not really recommended. It's always best to generate the SQL, which you or your DBA can then inspect before applying the changes live.
Chris Pratt is correct BTW.
I had downloaded a project in which I needed to just run "Update-Database
Here are the quick screenshots
Then at the bottom of Visual Studio
PM> Update-Database
DONE
I can use package manager to run 'update-database -verbose' locally.
Probably a stupid question but I can't find it online - once my website is deployed - how can I run this manually on the server?
Secondarily - what other strategies would you recommend for deploying database migrations to production - and how would they be preferable?
Thanks
You have a couple of options:
You could use update-database -script to generate the SQL commands to update the database on the server
You could use the migrate.exe executable file that resides in the package folder on /packages/EntityFramework5.0.0/tools/migrate.exe. I've used it successfully in the past with Jet Brains' Team City Build Server to setup the migrations with my deploy scripts.
If you're using IIS Web Deploy you can tell the server to perform the migrations after publish (see pic below)
You could setup automatic migrations, but I prefer to be in control of when things happen :)
Update: Also, check out Sayed Ibrahim's blog, he works on the MsBuild Team at Microsoft and has some great insights on deployments
I know that the question is already answered, but for future reference:
One of the options is to put something like this in the constructor of your DB context class:
public MyDbContext()
{
System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, Configuration>());
}
For us, the DBAs are the only group to have access to the production (and pre-production) environments. We simply use the Update-Database -Script package console command to get the Sql required to update the database. This gets handed off to them where they can validate it, etc.
Maybe a little too simplistic for some but it works.
HTH.
A simple solution: running Update-Database from your local Package Manager Console providing a connection string parameter with the production connection string. You also have to provide the connection provider name (SqlServer in this example code):
Update-Database -ConnectionString <your real remote server connection string here> -ConnectionProviderName System.Data.SqlClient
Instead of the connection string you can use a connection string name present in your app.config file connectionStrings section:
Update-Database -ConnectionStringName <your connection string name here>
You must have permissions to access that server from your local machine. For example, if you are able to connect to the server from a Sql Server Management Studio you can use this.
Note that this approach is not recommended for a real production system, you should use something like what is explained in the accepted answer. But it can help you with quick hacks in development remote servers, test environments, etc.
I personally like to setup automatic migrations that run every time the application's start method is called. That way with every deployment you make you have the migrations just run and update the application automatically.
Check out this post from AppHarbor. http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-3
The gist is basically you want to enable auto migrations then call the DatabaseInitializer from your code, either from the OnModelCreating method or from your Global.asax.
You can get the scripts using EF commands (update-database -script) or you can write the script manually. This is not the most important thing about updating the database in production environment. For me, the most important thing is to be sure that all the scripts were run correctly and they have affected records as expected.
In my opinion, you should have a preproduction environment and the database should be a copy of the production environment. This way, you can run the scripts and deploy the application in a pretty similar environment and see if there are any problems. Sometimes the scripts are executed correctly in DEV environment but they fail in production environment. To avoid a headache, you should simulate the production environment in a preproduction environment.
Regarding the scripts, if the team has more than one developer I prefer to categorize the scripts in structure scripts and data scripts. Structure scripts alters the structure of the database (add a table, add a column to a table, etc.) and data scripts inserts/updates/deletes records. Also, each script should specify its dependencies so they cannot be executed in the wrong order. A data script that inserts rows in table A cannot be executed until table A has been created. This is what I do:
-Define a table for registering the executed scripts. For example: ExecutedScriptsHistory.
-Each script has a number and a name.
-After a script is executed, a new row is inserted in table ExecutedScriptsHistory.
-Before a script is executed, it checks its dependencies. In order to do that, it checks if the scripts have been executed (exists in table ExecutedScriptsHistory).
After you have run the scripts, you can check if all the scripts have been executed checking ExecutedScriptsHistory. This strategy is similar to the one chosen by Microsoft in EF Migration but you have full control of it.
just to give everyone the simple answer.
This is the "Update-Database"
In your Migrations folder, Configuration.cs:
internal sealed class Configuration : DbMigrationsConfiguration<projectname.Models.dbContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true; // Update-Data -Force (deletes columns etc)
}
And to "Enable migrations" in the first place on a remote server, add this to your Global.asax.cs file:
protected void Application_Start()
{
....
System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<dbContext, Migrations.Configuration>());
Built an app locally with an EF code-first database - not sure how to upload it to a shared hosting environment such as GoDaddy. It makes sense that something would be amiss because on the shared hosting your code can't just go create a database, but on the flip side I can't find anything to copy the CREATE sql and create it on the server like you would with MySQL
Feel a little silly because I've been using .NET for over a year now but at work the databases are already set up and we have full control over our environments.
If the database has no data that you need to preserve the easiest method is just to install the app on the new host and set the connection string to your new database on the host. On the first attempt to load a page accessing the database, the database will automatically be created (note that you need to load a page which hits the database - sometimes the home page is not sufficient).
This method is a lot more straightforward than generating SQL and then executing it on the production database.
If there is data that you need to preserve then the best method will be taking a backup and installing the backup on the host. In SSMS simply right-click the database in the left pane, then Tools > Backup... To restore on the server connect to the server in SSMS and right-click the 'Database' node in the left panel and select 'Restore Database...' I'm not sure if the host provides a direct connection from SSMS but they should at a minimum have a mechanism to restore a .bak file.
Going forward you should ensure that you can execute SQL on your database as a very convenient method for deploying EF Migrations is to generate the SQL update script on the development server and then deploy this by executing it in production.
Depending on your web host, you may be able to restore the database. If this is an option, simply back up your database on your local machine and restore it on the server via the management console.
You can back up your local database using SQL Server Management Console. This works well even for larger databases as you can directly restore all your data, your schema, etc.
I've had experience with three different hosts so far and all of them have this as an option. You'll usually find this under the Database tab for the web site. The rest from there is up to you because it's usually different across the various hosts.
We're considering using EF 4.3.1 code-based migrations, but aren't clear about how to integrate Migrations with our present dev/deployment methodology...
The app in-question is a desktop WPF app, with each desktop having its own SQL Server instance (each with 4 separate databases). It is deployed into a "field" environment with zero local IT support. Any database migration must be done using SQL scripts executed by the installer (probably InstallShield). There will not be anyone available who can run a command at a PMC prompt to upgrade the db when it is deployed/upgraded at a field location. Thus the ultimate "output" from EF Migrations must be a set of SQL scripts, which the installer will selectively apply.
Also, we have multiple developers making concurrent database changes.. there is NO DBA. Each developer simply checks-in their code (model) changes to TFS, and the next time they do get-latest, the changes to the model automatically cause a new database to be created on their dev system. So how can we now have each developer perform their own local migrations (rather than deleting/recreating their local databases), and then manage/consolidate/combine those migrations? And what about collisions?
During dev and unit-testing, each developer may delete their (entire) local database multiple times during a single checkout/checkin iteration. This works great with Code First, since the database gets automatically rebuilt when the app is restarted. But this means that the _MigrationHistory table in the database also gets deleted. How do we handle this? Don't we need the migration history of each dev system? If not, then where/how do we detect the aggregate changes which need to be applied to the delivered system?
I can see the value of using Migrations to deal with the mechanics of migrating a database, but what's not clear is how to take advantage of it without introducing a centralized database "change-control" bottleneck into the dev cycle, and thus losing one of the key benefits of Code First.
Any insight/advice would be greatly appreciated!
DadCat
I know this is an old question but I thought I'd post some of my experiences with EF Migrations (v6.1).
Each dev will be fine. Migrations are put into classes with a timestamp in the name, so no collisions will happen. The DB on the dev's machine will be updated after doing a get latest and running the app (or the update-database command).
Deleting the local db and recreating is fine. Just make sure the dev runs update-database before adding additional migrations or things will get out of sync. I'm a bit confused as to why they'd need to delete the local DB, but that's out of scope. You may find that your process needs to change to accommodate EF Migrations.
I can't help you with the installer question, as a similar question brought me here. The update-database command does have a -script option that will generate the proper change script, but I'm unclear how to automate that on a build server.