I have a database with data I would like to replicate to a SQL server. I am aware that I can add RavenDB replication after the fact in the Settings menu.
However, I don't find any setting for adding the SQL Replication bundle except during database creation (see image below).
Would it be best to create a new database with SQL replication enabled then replicate my old database to that one?
Judging by the Studio screenshot I assume RavenDB version 3.0/3.5
(in the upcoming version 4.0 this most likely would be handled differently)
Creating a new database with SQL replication bundle enabled, then replicating to the new database would work.
There is another option - simply add "SqlReplication" to key "Raven/ActiveBundles" in the database document. Then, cause the database to reload (disable then enable the database).
Like this:
Related
We have a sql database on AZURE, which is geo replicated to another server in different location.
We had incorrect pricing tier on this DB (which also transfered to the geo replica). In order to change it, i had remove DB from failover group and then delete replication link.
Now when i want to recreate the link, it says that DB with this name already exists (which of course does, i deleted the link but not the replicated DB).
Is there any way to recreate link on the existing DB or is the best practise to just delete the replicated DB and create it anew?
Azure Geo Replication Failover is a feature designed for automatically managing replications on database failures.
If it were a manual exception, such as incorrect pricing or schema errors, it would not correct/reflect by default because those databases are read-only, as shown below.
Solution:
1.Delete the database on the replica and re-add the database from the primary server again; it will automatically configure the latest database features; there is no need to delete the link.
Step2:
Create a new replica link from primary to failover again
I am working on a desktop application(WPF) which is using sql server database to store and fetch the data. Now due to change in user requirement, there are some extra columns added in some tables and I have made changes in NHibernate mapping classes as well and application is ready for new release.
Now if I make database related changes in Production environment, the users who are using old version of the application will get NHibernate exception since the mappings are changed.
Is there any solution to avoid these kind of scenarios? Please need suggestions.
You should need to do manually. I have experience like this case.
1.Take backup for those table in production server which tables are all you changed mapping and altered new columns.
2.Drop those tables from production server.
3.move local tables schema (tables which you have mapping and new columns) into production server.
4.Now move the production data from backup table into source table based on mapping.
Today I maintain project that has really messy DB that need a lot of refactor and publish on clients machines.
I know that I could add a SQL Server Database project that contains just scripts of the database and creates a .dacpac file that allows me to change clients databases automatically.
Also I know that I could just add an .mdf file to the App_Data or even to Solution_Data folder and have my database there. I suppose that localDb that already exists allows me to startup my solution without SQL Server
And atlast i know that Entity Framework exist with it's own migrations. But i don't want to use it, besouse i can't add and change indexes with it's migrations and i don't have anought flexibility when i need to describe difficult migrations scenarios.
My goals:
Generate migration scripts to clients DB's automaticaly.
Make my solution self-contained, that any new Programmer that came to project don't even need to install SQL Server on his machine.
Be able to update local (development) base in 1-2 clicks.
Be able to move back in history of db changes (I have TFS server)
Be able to have clean (only with dictionaries or lookup tables) db in solution with up to date DB scheme.
Additionally i want to be able to update my DB model (EF or .dbml) automatically or very easy way.
So what I what to ask:
What's a strengths and weaknesses of using this 2 approaches if I want to achive my goals?
Can be that I should use sort of combination of this tools?
Or don't I know about other existing tool from MS?
Is there a way to update my DAL model from this DB?
What's a strengths and weaknesses of using this 2 approaches if I want to achive my goals?
Using a database project allows you to version control all of the database objects. You can publish to various database instances and roll out changes incrementally, rather than having to drop and recreate the database, thus preserving data. These changes can be in the form of a dacpac, a SQL script, or done right through the VS interface. You gain a lot of control over deployments using pre- and post-deployment scripts and publishing profiles. Developers will be required to install SQL Server (the developer/express edition is usually good enough).
LocalDB is a little easier to work with -- you can make your changes directly in the database without having to publish. LocalDB doesn't have a built-in publish process for pushing changes to other instances. No SQL Server installation required.
Use a database project if you need version control for your database objects, if you have multiple users concurrently making changes, or if you have multiple applications that use the same database. Use LocalDB if none of those conditions apply or for small apps that require their own standalone database.
Can be that I should use sort of combination of this tools?
Yes. According to Kevin's comment below, "If the Database Project is set as your startup project, hitting F5 will automatically deploy it to LocalDB. You don't even need a publish profile in this case."
Or don't I know about other existing tool from MS?
Entity Framework's Code First approach comes close.
Is there a way to update my DAL model from this DB?
Entity Framework's POCO generator works well unless you make changes to your DAL classes, then those changes get lost the next time you run the generator.
There is a new tool called SqlSharpener which can generate classes from the SQL files in a database project. I have not used it so I cannot vouch for it but it looks promising.
One way for generating client script for DB changes is to use database modeling tool like ERWin Which have a free community edition. The best way to meet your database version control requirement and easy script generation is Redgate SQL Source Control. Using Redgate tool you will meet the first five goals mentioned. Moreover, you can now update EF Model by single click after changing DB schema (i.e. Database first approach) as required in goal 6.
I do not recommend using LocalDB at all. It always make issues with source control like "DB File is in use and can't commit...” In addition, the developer in the project will not have common set of updated data to work on unless a developer add test data to the database and ask others to get latest version and overwrite their own database Or generate update script by the previous mentioned tool and ask every developer to run it on his localDB.
The best way in your situation is to use SQL Server on network. A master version that all the developers use. Since you have version control on the database using previously mentioned tool, you can rollback any buggy change in the database server.
If you think that RedGate tool is expensive for the budget of your project. A second approach is to generate single SQL file from your database that has all database object and the other developers update the SQL file in source control per their changes. This can be done easily by using schema compare tool in visual studio and appending the generated script to SQL file in the source control. With EF DB First approach, you will not have to add many migration classes as in EF Code first.
I'm working on a project as an outsourcing developer where i don't have access to testing and production servers only the development environment.
To deploy changes i have to create sql scripts containing the changes to make on each server for the feature i wish to deploy.
Examples:
When i make each change on the database, i save the script to a folder, but sometimes this is not enought because i sent a script to alter a view, but forgot to include new tables that i created in another feature.
Another situation would be changing a table via SSMS GUI and forgot to create a script with the changed or new columns and later have to send a script to update the table in testing.
Since some features can be sent for testing and others straight to production (example: queries to feed excel files) its hard to keep track of what i have to send to each environment.
Since the deployment team just executes the scripts i sent them to update the database, how can i manage/ keep track of changes to sql server database without a compare tool ?
[Edit]
The current tools that i use are SSMS, VS 2008 Professional and TFS 2008.
I can tell you how we at xSQL Software do this using our tools:
deployment team has an automated process that takes a schema snapshot of the staging and production databases and dumps the snapshots nightly on a share that the development team has access to.
every morning the developers have up to date schema snapshots of the production and staging databases available. They use our Schema Compare tool to compare the dev database with the staging/production snapshot and generate the change scripts.
Note: to take the schema snapshot you can either use the Schema Compare tool or our Schema Compare SDK.
I'd say you can have a structural copy of test and production servers as additional development databases and keep in mind to always apply change when you send something.
On these databases you can establish triggers that will capture all DDL events and put them into table with getdate() attached. With that you should be able to handle changes pretty easily and some simple compare will also be easier to apply.
Look into Liquibase specially at the SQL format and see if that gives you what you want. I use it for our database and it's great.
You can store all your objects in separate scripts, but when you do a Liquibase "build" it will generate one SQL script with all your changes in it. The really important part is getting your Liquibase configuration to put the objects in the correct dependency order. That is tables get created before foreign key constraints for one example.
http://www.liquibase.org/
I am having a problem with one database on my SQL Server 2005 production server.
A number of databases are already set up for mirroring, however when I right click and go to properties in SSMS, on one particular database there is no "Mirroring" property page available.
I have done the normal tasks, such as setting Full Recovery model, running a full backup of the database and backing up the logs.
I can't see that this is a server specific issue as other databases are happily mirroring.
I've looked around and I can't see that I'm missing a setting, any help would be appreciated.
Thanks.
EDIT: This is nothing to do with the Mirror Database yet, I can't get as far as specifying the Mirror Database , I cannot see the "Mirroring" page on the principle.
EDIT: I have managed to setup mirroring using t-sql commands. However I am still unable to see the "Mirroring Page".
UPDATE: This applies to the Transaction Log Shipping option as well. I can successfully set it up in SQL but not through SSMS.
Check theese items:
2 . The mirror database has to be created from a full backup of the principal server and should be restored in "Restore with Norecovery" model. It is followed by a restore of transaction log backup of the principal database so that the log sequence numbers of the mirror and the principal database are in synch with each other.
3 . The mirror database must have the same name as the principal database.
...
8 . DB Mirroring is available in Enterprise, Developer and Standard Editions, however, please refer to Microsoft website for a comparison chart as some features are not available in the Standard Edition. SQL Server Workgroup and Express Editions can only be used as witness servers.
Database Mirroring in Microsoft SQL Server 2005
Test monitoring with sp_dbmmonitorresults (Transact-SQL)
I don't have the answer, but I ran across the same symptom yesterday, and I remembered your question here, hahaha. My problem was that I set up database mirroring using the wizards, but one of the systems had a firewall blocking the mirroring port. The wizard setup went all the way to the final part of enabling database mirroring, and then errored out - but at that point, mirroring was already set up. Mirroring worked great, but there was something in the database metadata that wasn't set quite right. Even when I removed the firewall, parts of SSMS acted as if mirroring wasn't set up for that particular database, even though it was.
I then set up additional databases for mirroring (with the firewall off) and they worked great. My solution was to remove mirroring on that database and then add it again, and it worked fine. Doesn't sound like that's worked for you, though.
I ended up having to have a Microsoft Support call for the problem I was facing. Anyway after sometime and a number of support sessions they worked out that the database with the problem had an ID of 4 in sys.databases. IDs 1-4 are usually reserved for the system databases and if a database has any of these ids the T-log or Mirroring properties are not displayed. So somehow our database got the ID 3 and now I better get on and detach and reattach some databases to reassign IDs.