I want to take a snapshot of all table, view and procedure definitions, and diff this snapshot against another version of the same schema. (By snapshot I mean the schema definition stored in some text file.)
I am not interested in procedure bodies, only in what is relevant to my DAOs. (Maybe you could call that a schema interface...?)
Is there a one-command way of creating such snapshot for an Oracle schema?
You can use Oracle SQL Developer "Database Diff" to do this. You can select the two Oracle schemas to be compared and it produces all the differences
The good thing about this tool is that it allows you to select what to consider when differences are produced, and, then, you have the option of only comparing package specs
Related
I was assigned the task to create a simple Database Management System in a class so I looked up Postgres and noticed that the CLI tool (psql) has commands (\d and \l) that output information about the database and columns of a table in the form of tables like when you do a SELECT. So my question is If Postgres manages user tables inside system tables? and that way when you do \d or \l you are actually doing a SELECT on those system tables. This is just to understand if that would be a good way of managing tables in a database or not and just use regular data structures like lists.
It does indeed. You can run psql with -E to see the queries it is using.
Then check the online manuals
The items to search for are "system catalogs" and "INFORMATION_SCHEMA". The latter is a standard way of describing database schemas and should mostly work between different RDBMS.
Yes, Postgres uses tables that it creates to manage the tables that you create.
There is an entire chapter in the documentation explaining. To quote:
The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information. PostgreSQL's system catalogs are regular tables.
As mentioned in the other Answer, the SQL standard requires metadata be provided in some table structures as defined within the standard. These must be housed within a schema named exactly INFORMATION_SCHEMA. Postgres provides that schema and its prescribed tables, but implements them as a view on the actual system tables. See the chapter on INFORMATION_SCHEMA in Postgres documentation.
You can access the metadata, such as to get a list of all the tables you have defined, or get a list of all the columns you defined in a particular table. To do so, perform a query in SQL using SELECT like any other query.
For portability, meaning to write code that works in other database systems in addition to Postgres, query against INFORMATION_SCHEMA.
For additional details not required by the SQL standard, and for Postgres-specific info, query against the Postgres-specific system tables. Their names all start with pg_.
I have a SQL Server database that uses schemas to logically group objects; there are ten schemas in the database.
If I baseline my database and create the schema history table in the “foo” schema, will Flyway apply a migration from the migration folder that operates on an object in the “bar” schema?
Do I need one folder of migration scripts for each schema in the database? The documentation explains how to specify schemas on the command line but doesn’t make it clear as to why I must.
The list of schemas on the command line has two effects:
the first named schema is where the history table goes
the named schemas are the ones that are cleaned by flyway clean
(Note - in 6.1 the command line defaultSchema parameter was introduced to separate these usages)
Migrations can refer to any schema in the database that you have access to - indeed, some objects may exist in one schema but depend on objects in another. If you're happy with the history table to go in dbo, and want to control the whole database with Flyway, just don't set these parameters. A folder of scripts per schema may help you with maintaining them but it is not necessary.
I have a table under dbo and an almost identical table under a schema called tmp. Visual Studio Schema Compare does not appear to let me select one set of dbo-based objects and compare them with a similar set of tmp-based objects.
The database server is locked down and it is not possible to create a second database. Also, SQL server is unusable on a local dev machine due to resource constraints. The tmp schema would allow me to make changes to tmp, then compare and push those changes to the dev schema of "dbo".
What's the best way to compare these two sets of objects?
You can compare your objects with different schemas with ApexSQL Diff and it has free Community edition.
By creating custom schema mapping, you’ll be able to match objects with different schemas compare them and synchronize if needed.
If you just want to compare objects to see differences and create a merge script, you can check out a free tool - ApexSQL Compare.
Since RedGate tool is already mentioned, one more tool that can help you out is dbForge Schema Compare.
Two methods come to mind. Try redgates sql-compare tool, worth its weight in gold imo.
Another option would be to use the 'generate scripts' functionality of ssms and then use the diff tool of your choice to compare the resultant sql text files.
We have some sets of the tables in same database like table1 and table_copy. Now we are planning to migrate the old data from table1 to table_copy which is currently in use. But before that we have to compare the definitions of the tables so that the data import will be hassel free. Can we compare the table definitions with a sybase query.
I searched over net by all I get approaches to compare the data in two tables. but we intend to compare the definitions only.
You could do queries on sysobjects, syscolumns and systypes.
Or you could compare with diff (or perl or whatever) the outputs of sp_help.
However isn't this really a development and testing problem? You should perhaps copy the database into a pre-production database and test your scripts - repeat until perfect.
If you can only do the full migration on the Production database for some resources reason (time, money, servers,) then you need full dumps before starting.
Isn't the DDL for these two tables saved and accurate in a Version Control system somewhere? Perhaps they're from a 3rd party system though, so you don't have that.
SQL Server 2005. Is there a sql query that will return a text field containing the same type of schema info as you would find in doing a right click table -> Script Table As -> Create To (or Alter To) from SQL Server Management Studio ?
I'm looking for a single/flat format that describes the entire table, including constraints, indices, etc.
I am aware of:
sp_help table_name
but that doesn't provide the single flat format I'm looking for. Ideally it would be in a scriptable format, such as the AlterTo result that could be executed against the server.
This is for a scheduled process that documents table schemas on a nightly basis for checking in to version control (SVN).
Not really. A table def is a collection of columns, constraints etc.
There is an SVN plugin that may help called ScriptDB4SVN. I've not used it personally, I'm going on hearsay.
Was searching the 'net again for an answer to this, and came across this SO question. It doesn't accurately capture all the same data as SQL Management Studios Create-to, but enough for my purposes (scripting the database structure for version control purposes).
There is no such command in SQL Server. This is primarily because the Scripting facilitiy is actually in SMO and not in SQL Server itself. There are a number of free console command-line tools that can do it that you could call via xp_CmdShell.
However, if you really want to do this from T-SQL, then you will need a script or stored procedure that enumerates all of the tables attributes, columns, column datatypes, defaults, nullabilty, etc. etc. and then reassembles it into a CREATE TABLE script. This is a Huge task. That's the bad news. The good news is that someone (Lowell Izaguirre) has already done this and posted it in this article (http://www.sqlservercentral.com/scripts/Miscellaneous/30730/) at SQLServerCentral.Com.
Enjoy.
Not really - you can either use C# (or VB.NET) and SMO (SQL Management Objects) to script out your database objects (tables and all), or you can use SQL to get the list of columns for a table:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Your Table Name here'
But I don't know of any easy way in SQL itself to create Create/Alter scripts for database objects, sorry.
Marc