We have live and demo systems, each using of a pair of databases.
One database often reports from the other.
Quite often the demo site has a reference like this
SELECT Columns
FROM OtherDatabase_demo.dbo.Tablename
So the live version would say:
...FROM OtherDatabase.dbo.Tablename
When it comes to publsihing I compare the stored procedures between live and demo (using dbForge Schema Compare in my case) every differing reference is highlighted, and creates a lot of noise.
Is there any way to abstract these references so I can make that distinction in one single location?
Yes, use a synonym. In one database:
CREATE SYNONYM dbo.MyTableName FOR OtherDatabase_demo.dbo.Tablename;
And in the live version:
CREATE SYNONYM dbo.MyTableName FOR OtherDatabase.dbo.Tablename;
Now your script can say...
SELECT Columns
FROM dbo.MyTableName
...in both databases, allowing your procedures to be identical.
Your diff scripts may pick up the different definitions for the synonyms, but hopefully you can ignore those (either with the tool or just consciously).
We've asked for the ability to alias a database, but they don't understand how useful this could be:
http://connect.microsoft.com/SQLServer/feedback/details/311079/expand-synonym-to-other-entities-database-linked-server
http://connect.microsoft.com/SQLServer/feedback/details/288421/allow-create-synonym-for-database
I have read the following article. They have quoted that,
SQL Server is a case-sensitive back-end application. This means that a
table named "addr" is distinguished from a table named "ADDR."
However, because Microsoft Query is an MS-DOS-based application, it is
unable to distinguish cases; therefore, Microsoft Query views "addr"
and "ADDR" as the same file.
Now I wanted to know what to they mean by case-sensitive back-end application? Is it safe to use the query with case-insensitivity?
Thanks in advance.
SQL Server with default collation will return you the same result, doesn't matter which case you use for your query.
Collation can be set at various levels
Server
Database
Column
For more info can be found out here
Please check Applies To section of the article you referenced. KB article applies to product from Microsoft for which they no longer provide any support.
I have to develop database development standards for our organisation for SQL Server and any code that interfaces to it. The code used can be anything from .NET code to VBScript to SQL Server Jobs.
Does anyone have a good link for this kind of thing?
My quick list is follows:
1) Naming Conventions
-- Stored Procedures usp_AppName_SPName
-- Functions usf_AppName_SPName
-- Indexes IX_TableName_IndexName
-- Tables AppName_TableName
-- Views VW_Name
2) Allocation of permissions to roles, never directly to users or groups
3) Allocation of roles to groups, never directly to users
4) Use of minimal permissions
5) No inline sql in code, always use SP or Functions
6) Use of explicit transactions
7) Readonly transactions where applicable
8) Always use explain plans to ensure sql is performant.
What other things do we need to cover? I am sure that there are lots of things....
Since we are talking best-practices I'd throw in a few things to avoid:
avoid use of xp_cmdshell
avoid dynamic sql unless strictly
necessary (such as for dynamic pivoting)
avoid cursors (if not on temp
tables)
P.S. Btw - I am doing all of the above ;)
I found the following quite useful:
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://www.codeproject.com/KB/database/sqldodont.aspx
Also consider using multiple schemas. Use AppName.TableName instead of AppName_TableName, where AppName is a schema. The AdventureWorks sample does this, for instance.
I have to take issue with your first item right off the bat. While I know a lot of people like to use prefixes for stored procedures, tables, and the like, I've never had much use for that convention. When you start to get a lot of stored procedures that all start with "usp_", and you click to the expand the "Programmability\Stored Procedures" folder in Management Studio, it can be rather unwieldly to navigate.
Instead, require a prefix to match the logical feature set/functional group. What those prefixes are will vary by application or database. Then if you want to distinguish a stored procedure from a table, add your "_usp" requirement as a suffix.
For tables: you want something in your naming convention to distinguish between Application data (lookup tables) and User data.
Aren't roles and groups the same thing in SQL Server?
A few others...
Avoid using UDFs in WHERE clauses
Disallow direct SQL in applications
(always use SPs)
Use comment blocks in front of
views/procs/functions including a
revision history and/or revision
date
Use ANSI join syntax
Limit use of triggers, especially
for replicated tables
How to create a dynamic SQL statement, that will update any table given as one of parameter. Here I believe, i couldn't use "Set Column1 = Value ....." as the columns will differ according to the table.
This is an extremely poor idea. You can create massive havoc with your database doing such a thing. I can't imagine any dba who would allow it. You need to know the specifics of a table to insert into it properly, you need to be aware of what fields are required and what fields have default values. You need to know what kind of information and data types should be in each field so that you do not send bad data to the database. One proc that does all cannot properly check these things and certainly can't ever be properly tested. Further it means permissions must be at the table level which is a poor choice for internal security as well as for SQL injection attacks.
Could you provide more context? Are you executing arbitrary SQL statements from within scripts, such as Perl, PHP, or Python? Are you just trying to get a command-line .sql script working? What database server are you working on?
The solution can vary widely depending on your situation.
I'm looking for a way to validate the SQL schema on a production DB after updating an application version. If the application does not match the DB schema version, there should be a way to warn the user and list the changes needed.
Is there a tool or a framework (to use programatically) with built-in features to do that?
Or is there some simple algorithm to run this comparison?
Update: Red gate lists "from $395". Anything free? Or more foolproof than just keeping the version number?
Try this SQL.
- Run it against each database.
- Save the output to text files.
- Diff the text files.
/* get list of objects in the database */
SELECT name,
type
FROM sysobjects
ORDER BY type, name
/* get list of columns in each table / parameters for each stored procedure */
SELECT so.name,
so.type,
sc.name,
sc.number,
sc.colid,
sc.status,
sc.type,
sc.length,
sc.usertype ,
sc.scale
FROM sysobjects so ,
syscolumns sc
WHERE so.id = sc.id
ORDER BY so.type, so.name, sc.name
/* get definition of each stored procedure */
SELECT so.name,
so.type,
sc.number,
sc.text
FROM sysobjects so ,
syscomments sc
WHERE so.id = sc.id
ORDER BY so.type, so.name, sc.number
I hope I can help - this is the article I suggest reading:
Compare SQL Server database schemas automatically
It describes how you can automate the SQL Server schema comparison and synchronization process using T-SQL, SSMS or a third party tool.
You can do it programatically by looking in the data dictionary (sys.objects, sys.columns etc.) of both databases and comparing them. However, there are also tools like Redgate SQL Compare Pro that do this for you. I have specified this as a part of the tooling for QA on data warehouse systems on a few occasions now, including the one I am currently working on. On my current gig this was no problem at all, as the DBA's here were already using it.
The basic methodology for using these tools is to maintain a reference script that builds the database and keep this in version control. Run the script into a scratch database and compare it with your target to see the differences. It will also generate patch scripts if you feel so inclined.
As far as I know there's nothing free that does this unless you feel like writing your own. Redgate is cheap enough that it might as well be free. Even as a QA tool to prove that the production DB is not in the configuration it was meant to be it will save you its purchase price after one incident.
You can now use my SQL Admin Studio for free to run a Schema Compare, Data Compare and Sync the Changes. No longer requires a license key download from here http://www.simego.com/Products/SQL-Admin-Studio
Also works against SQL Azure.
[UPDATE: Yes I am the Author of the above program, as it's now Free I just wanted to Share it with the community]
If you are looking for a tool that can compare two databases and show you the difference Red Gate makes SQL Compare
You didn't mention which RDMBS you're using: if the INFORMATION SCHEMA views are available in your RDBMS, and if you can reference both schemas from the same host, you can query the INFORMATION SCHEMA views to identify differences in:
-tables
-columns
-column types
-constraints (e.g. primary keys, unique constraints, foreign keys, etc)
I've written a set of queries for exactly this purpose on SQL Server for a past job - it worked well to identify differences. Many of the queries were using LEFT JOINs with IS NULL to check for the absence of expected items, others were comparing things like column types or constraint names.
It's a little tedious, but its possible.
I found this small and free tool that fits most of my needs.
http://www.wintestgear.com/products/MSSQLSchemaDiff/MSSQLSchemaDiff.html
It's very basic but it shows you the schema differences of two databases.
It doesn't have any fancy stuff like auto generated scripts to make the differences to go away and it doesn't compare any data.
It's just a small, free utility that shows you schema differences :)
Make a table and store your version number in there. Just make sure you update it as necessary.
CREATE TABLE version (
version VARCHAR(255) NOT NULL
)
INSERT INTO version VALUES ('v1.0');
You can then check the version number stored in the database matches the application code during your app's setup or wherever is convenient.
SQL Compare by Red Gate.
Which RDBMS is this, and how complex are the potential changes?
Maybe this is just a matter of comparing row counts and index counts for each table -- if you have trigger and stored procedure versions to worry about also then you need something more industrial
Try dbForge Data Compare for SQL Server. It can compare and sync any databases, even very large ones. Quick, easy, always delivers a correct result.
Try it on your database and comment upon the product.
We can recommend you a reliable SQL comparison tool that offer 3 time’s faster comparison and synchronization of table data in your SQL Server databases. It's dbForge Data Compare for SQL Server.
Main advantages:
Speedier comparison and synchronization of large databases
Support of native SQL Server backups
Custom mapping of tables, columns, and schemas
Multiple options to tune your comparison and synchronization
Generating comparison and synchronization reports
Plus free 30-day trial and risk-free purchase with 30-day money back guarantee.