Several databases:
DB_Dev
DB_Test
DB_Prod
When new columns are needed or existing columns need to be altered, they are always changed on DB_Dev first and then the changes copied to the others when everyone is happy.
Is there any tools that will look at two databases, show the changes, and allow to make those same changes to the second database automatically? Changes will only be forward - ie, DB_Dev will never be out of date.
Related
I have a production and development database (on different systems of course). Many months ago, I copied the production database to the development system. I used exp/imp at the time. Since then there has been quite a few changes in the production database I would like to copy down to the development database. I'd rather not wipe out the development database and start over because of data I've had to add to the development database.
My original thought was to use MERGE INTO to copy the new records. But this apparently requires me to do this for tables, and list all fields of all tables. We're talking hundreds of tables and thousands of fields here. Not a pretty solution.
Is there an easier way?
Why not use the TABLE_EXISTS parameter of impdp to append the new data to the existing tables? Duplicate keys will error off but the rest of the data should still import. The results will be a bit messy. Prior to running TRUNCATE any tables in test where you can just bring the entire production table. Disable FK. Re-enable after import.
- -
Another option create a database link and generate INSERT/SELECT into all tables where data not in existing test table. You probably also want to disable FK prior to running and re-enable when done.
A while back, I made and published software with an sdf database. Now I want to improve it and add more features: new forms and new tables in the database. How can I get the data stored in a table (where the table is still has the same proprieties in my new database) and added them to my new database?
Typically, the way to approach this problem is not to move the data to a new database, but rather use the SQL ALTER statement to add or remove the columns you need from the old database in place. The installer for the new program needs to be smart enough to detect the old database file, and you write code for the installer (or a check when the program starts up) that is able to handle the upgrade process.
This works especially well if you are doing source control correctly. With source control, you have to commit or check in changes for the code, but it's no good committing a change that needs the database to have a column that's not yet available. Thus a good source control environment encourages you to write the ALTER statement to add that column as part of the rest of the feature work. Someone else needs a different column on the same table? They write their own ALTER statement. Later, their branch can merged with yours, but the database still ends up exactly as it needs to be. Moreover, these commits to the database project can then be collected and used for the upgrade process when you are ready to publish the application.
Basically I need something to generate SQL Server change scripts for data differences only, based on the data differences between two tables with the same schema.
We will have a table with approx 250,000-330,000 rows and 10-12 columns, and two instances of the table:
The Master table, populated with records from the production system.
the Sandpit table, also populated from the production system - but in which the user can add / remove rows and edit cell contents.
Once the user is happy with their edits they need to generate a change script which makes the necessary changes to an instance of the Master table in a variety of servers (test, pre-prod, prod), so it needs to be reliable. It's safe to assume that all versions of the master data will be the same when the script is eventually run.
They also need to be able to re-run the change script for self-testing (restoring the master back to it's original state would be a separate process, out of scope for this question).
Design of the table schema is not yet done, and can be tailored to suit this purpose.
SQL Server 2008 Standard edition, upgrade likely (but still standard edition).
I understand RedGate is pretty much the industry standard / leading choice for generating SQL change scripts but their website focuses a lot on managing schema changes so not sure if it's appropriate to use here. I'm familiar with using SQL Server myself but it's been a few years - not sure if the inbuilt functionality is up to it or not (both being technically capable + user friendly enough). The end user will be a competent SQL user but comes from the business side not IT (not SQL Admin grade).
You should be able to do this from Visual Studio using SSDT (SQL Server Data Tools). You need to do a data comparison between the source and target tables, which will then generate a change script.
I have a structured database and software to handle it and I wanted to setup a demo version based off of a simple template version. I'm reading through some resources on temporary tables but I have questions.
What is the best way to go about cloning a "temporary" database while keeping a clean list of databases?
From what I've seen, there are two ways to do this - temporary local versions that are terminated at the end of the session, and tables that are stored in the database until deleted by the client or me.
I think I would prefer the 2nd option, because I would like to be able to see what they do with it. However, I do not want add a ton of throw-away databases and clutter my system.
How can I a) schedule these for deletion after say 30 days and b) if possible, keep these all under one umbrella, or in other words, is there a way to keep them out of my main list of databases and grouped by themselves.
I've thought about having one database and then serving up the information by using a unique ID for the user and 'faux indexes' so that it appears as 1,2,3 instead of 556,557,558 to solve B. I'm unsure how I could solve A, other than adding a date and protected columns and having a script that runs daily and deletes if over 30 days and not protected.
I apologize for the open-ended question, but the resources I've found are a bit ambiguous.
These aren't true temp tables in the sense that your DBMS knows them. What you're looking for is a way to have a demo copy of your database, probably with a cut-down data set. It's really no different from having any other non-production copy of your database.
Don't do this on your production database server.
Do not do this on your production database server.
Script the creation of your database schema. Depending on the DBMS you're using, this may be pretty easy. If you've got a good development/deployment/maintenance process for your system, this should already exist.
Create your database on the non-production server using the script(s) generated in the previous step. Use an easily-identifiable naming convention, like starting the database name with demo.
Load any data required into the tables.
Point the demo version of your app (that's running on your non-production servers) at this new database.
Create a script/process/job which looks at your database server and drops any databases that match your demo DB naming convention and were created more than 30 days ago.
Without details about your actual environment, people can't give concrete examples/sample code/instructions.
If you cannot run a second, independent database server for these demos, then you will have to make do with your production server. This is still a bad idea because of potential security exposures and performance impact on your production database (constrained resources).
Create a complete copy of your database (or at least the schema, with a reduced data set) for each demo.
Create a unique set of credentials for each of these demo databases. This account should have access to only its demo database.
Configure the demo instance(s) of your application to connect to the demo database
Here's why I'm pushing so hard for separate databases: If you keep copying your "demo" tables within the database, you will have to update your application code to point at those tables each time you do a new demo. Once you start doing this, you're taking a big risk with your demos - the code you keep changing isn't really the application you're running in production anymore. And if you miss one of those changes, you'll get unexpected results at best, and mangling of your production data at worst.
I'm working on a design of a relational database. It has several tables and there are multiple users on application level. I need to know that changes to a certain record of a certain table are made, by which user, which time, and what has actually changed. There is a table for saving the user's information and this table is also included in this behavior.
How should I do this in the SQL database design so I can let users see which one of them made these changes?
What you want is a Wiki-like versioning. Basically, for every table you want to keep versions, you'll want to create at least a copy of that table with the fields you mentioned added (userid, when it was added). That's probably all there is to it, as long as you only need to track changes. Then, upon an edit, you just create a backup of the current row in that copied table and put the new one in the actual table. This way you can (hopefully) add the versioning without having to touch existing presentational code.
It gets a little more tricky, if you need to record additional actions like creation of new rows and deletion.
If you need a code example, just have look under the hood of some Wiki like https://mediawiki.org/
For starters you can look at sql server version tracking mechanisms (row versioning or row changes). After that you can look at sql server audit features. I think sql server audit would be the best for your needs.
On the other hand, if you want to make ad-hok versioning then YOU MUST NOT go to triggers. Imagine, you must create triggers for all tables for inserts, updates and deletes. This IS bad practice.
I think ad-hoc versioning should be avoided (degradation in performance and difficult to support) but in case it cannot be avoided, I would surely use CONTEXT_INFO in order to track current user and then I would try to create something that would read the schema of the table, I would get changes by using sql server change tracking mechanisms and store that in a tablename, changeduser, changedtime, column, prevValue, newValue style. I would not replicate each and every table for the changes.