I have two databases production one and pre-production, I want to map the changes I make in the production database to get inserted into the pre-production database. The problem is that both databases are on different servers. Is it possible to create a trigger or any other process to insert/update the same table in the pre-production database if that table gets updated in the production database?
I am trying to create a trigger but cannot find a way to do so. Also, I cannot use SSIS it is not available in our package.
You'd have to do a linked server
This is not advised though as it could affect your production server's insert performance. Why not restore your pre-production db from your production's backup?
Related
I am wondering what the best way (or any way) to manage a database schema. I have a sql file with a bunch of statements like CREATE TABLE Users { id SERIAL PRIMARY KEY ....}; which represents the schema for my database.
I have postgres installed on my dev machine however am having trouble syncing the changes I make to the schema with the local database. Currently I just run drop the entire database and run the schema file on the database.
I figure there has to be a better way I don't know about. I will also need to be able to set a database up for production when the project becomes more stabilized and obviously dropping a table in production wont work.
Suggestions?
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.
I have SQL Server 2008 installed on my machine and also Reporting Services Configuration Manager. When I connect to SQL Server, I found two databases already there.
ReportServer
ReportServerTempDB
I know ReportServer is to store reports, data sources, snapshots, subscriptions, etc. But what is ReportServerTempDB for? Why is it created? Is that necessary (for our use)?
Read the documentaion on report server database
The databases are created together and bound by name. By default, the database names are reportserver and reportservertempdb, respectively.
Report Server Temporary Database
Each report server database uses a related temporary database to store
session and execution data, cached reports, and work tables that are
generated by the report server. Reporting Services does not re-create
the temporary database if it is missing, nor does it repair missing or
modified tables. Although the temporary database does not contain
persistent data, you should back up a copy of the database anyway so
that you can avoid having to re-create it as part of a failure
recovery operation. If you back up the temporary database and
subsequently restore it, you should delete the contents. Generally, it
is safe to delete the contents of the temporary database at any time.
However, you must restart the Report Server Windows service after you
delete the contents. If you delete the temporary database, you can
create a new database, and then run the Catalogtempdb.sql script to
add the table structure. The temporary database must have the same
root name as the primary report server database.
I'm working on automated tests for particular web app. It uses database to persist data (SQL Server in this case).
In our automated tests we perform several database changes (inserts, updates). And after tests have been executed we want to restore database to original state.
Steps will be something like this:
Create somehow backup
Execute tests
Restore data from backup
The first version was pretty simple - create table backup and then restore it. But we've encountered an issue with references integrity.
After that we decided to use full database backup, but I don't like this idea.
Also we were thinking that we can track all references and backup only needed tables not a whole database.
Last thoughts was about somehow logging our actions (inserts, updates) and then perform reverse actions (deletes for inserts, updates with old data for updates), but it looks kinda complicated.
May be there is another solution?
Actually, there is no need to restore the database in native SQL Server terms, nor to track the changes and then revert them back
You can use ApexSQL Restore – a SQL Server tool that attaches both native and natively compressed SQL database backups and transaction log backups as live databases, accessible via SQL Server Management Studio, Visual Studio or any other third-party tool. It allows attaching single or multiple full, differential and transaction log backups
For more information on how to use the tool in your scenario check the Using SQL database backups instead of live databases in a large development team online article
Disclaimer: I work as a Product Support Engineer at ApexSQL
If you wanting to do minimal changes to the database with Insert and Update, it is much better alternative to do those changes within transactions which can be rolled back at the end of the test. This way SQL server will automatically store information in regards what you changes and will reverse it back to state before test began.
BEGIN TRANSACTION http://technet.microsoft.com/en-us/library/ms188929.aspx
I think the better idea is to create test database.
You can also create Interface for methods, first implementation for real data (with real db) and the second one for test db.
You can create a database snapshot.
The snapshot will keep track of all changed data pages that are changed during your test. Once you are done, you can restore back form the snapshot to the previous state.
CREATE DATABASE [test_snaphot1] ON
( NAME = test, FILENAME =
'e:\SQLServer\Data\test_snapshot1.ss' )
AS SNAPSHOT OF [test];
GO
--do all your tests
RESTORE DATABASE [test] from
DATABASE_SNAPSHOT = 'test_snaphot1';
GO
You have to create a snapshot file for each datafile of your database. So if you have a database with 4 data files, then your snapshot syntax should include 4 snapshot files.
Found simple solution - renaming table.
Algorithm is pretty simple:
Rename table to another table, e.g. "table" to "table-backup" (references will refer to that backup table)
Create "table" from "table-backup" ("table" will not have any dependencies)
Perform any actions in the application
Drop "table" with dirty data (will not break references integrity)
Rename "table-backup" to "table" (references integrity will be kept).
Thanks
Is there any way that when setting up replication between 2 servers instead of specifying each stored procedure as an article to be replicated, you could actually just replicate ALL stored procedures/user functions?
For example I run replication to a secondary server just so I have an active backup server. As we develop the application and add new stored procedures to the primary server these are not replicated unless we add the new articles into the replication job, this obviously requires additional work to be completed.
Does anybody know of a shortcut?
There is no shortcut - you have to add the new article to replication explicitly. If you are just using this for backup, have you considered log shipping or database mirroring? That may be more "automatic" for you in that you'll get all tables, users, procs, functions, etc. and you don't have to remember to add a table or proc to the replication solution.