Is there any standard sql command that can show you the current RDBMS and version?
The reason for this question is that I am using a CMS remotely that use a SQL database, but I don't know which RDBMS is being used, so I thought maybe there is standard SQL command to print it, something similar to SQL server's ##version
This is not a direct answer to the question, but since there is no standard sql query or function to show the RDBMS, I will post the queries/functions/vars used to identify it.
-- SQL SERVER
SELECT ##version;
-- Postgres, mysql, mariadb
SELECT version();
-- Oracle
SELECT * FROM v$version;
-- sqlite
select sqlite_version();
Please pay attention that Mysql and Sqlite will show only the version and will not include engine name in contrast to other RDBMS.
I am working in Visual Studio and using the SQL manager built into the studio. Now I am connecting to several databases and I would very much like to be able to save and open my SQL queries and still have them access the correct database and table.
So:
Database servers:
db.company.com
databasenumber1
databasenumber2
databasenumber3
db2.company.com
databasenumber1
databasenumber2
databasenumber3
db3.company.com
databasenumber1
databasenumber2
databasenumber3
Now I wish to write an sql query that does something simple, lets say:
select * from users where userid = '12';
However I want to select this from database server db2 and from database databasenumber3.
How do I write that in a use statement? Or is there something other than "use"??
Working among several databases in once script file requires USE followed by GO statement.
USE db1;
GO
SQL statements ...
...
USE db2;
GO
SQL statements ...
...
Another option is to use server.dbname.tablename format but that strictly requires that all of your databases are hosted on same server.
SELECT * FROM server.db1.table1
SELECT * FROM server.db2.table2
...
How can I select data in the same query from two different databases that are on two different servers, one DB2 Server and the other a SQL Server?
On your sql server, set up a linked server to the db2 database.
Then write your query on sql server. I suggest that you use openquery for the db2 stuff. If you have to combine the data, populate a sql server temp table with the openquery results and work from there.
The reason I suggest this is performance. I have found that if you use this syntax
select somefields
from server.database.owner.table
where whatever
sql server will bring back the entire table from the linked server and apply the where clause afterwards.
You can set up a linked server http://support.microsoft.com/kb/222937
How to create a linked server
I have a project that requires me to do development in SQL Server 2005, but do deployments to a SQL Server 2000 box.
For 99% of the SQL code, I have no problems, everything appears to be backwards compatible.
Now I am just about to start adding all the Stored Procedures (SPs) to source control, and I like the idea of doing a drop-add each time the query is executed. I.E. If the SP already exists, first drop it. Then create/re-create the SP.
How do I do this in a single script, in a manner that is compatible with both SQL 2000 and SQL 2005, so that my scripts will just work during Development (2000) AND Production (2005)? I believe the syntax is slightly different, and the SP metadata is stored in different system tables.
Please assist with a working SQL script.
This works for both SQL 2000 and SQL 2005. I have tested it right now.
USE databasename
GO
IF object_id('schema.StoredProcedureName') IS NOT NULL
DROP PROCEDURE schema.StoredProcedureName
GO
CREATE PROCEDURE schema.StoredProcedureName
.. your code
Don't use system tables: use OBJECT_ID
I would also deploy using ALTER but maintain source control using CREATE. That is, I only ever use differential deployment scripts (with ALTER) but compare to my source control folder after release (which as CREATE)
I have both code history and simpler deployments: there is no need to drop/create all procs. What if you forget a permission for example?
I use Red Gate/SVN BTW
I think
IF OBJECT_ID('your_sp_name') IS NOT NULL
will tell you if it is there, although I can't test on 2000 at the mo...
FWIW
select * from sysobjects where type = 'p'
still works in SQL 2008, so am guessing that this is still acceptable as the lowest common denominator. DMV's weren't available in 2000.
You best option is staill the compatibility views, sysobects, syscolumns, etc
Check out the following link
http://msdn.microsoft.com/en-us/library/ms187376.aspx
Many of the system tables from earlier
releases of SQL Server are now
implemented as a set of views. These
views are known as compatibility
views, and they are meant for backward
compatibility only. The compatibility
views expose the same metadata that
was available in SQL Server 2000.
It seems to me that you recreate all STORED PROCEDUREs with respect of sys.sp_refreshsqlmodule like if is described in my old answer I'm looking for a reliable way to verify T-SQL stored procedures. Anybody got one?. The code of STORED PROCEDUREs will be one more time verified inclusive off dependencies.
Using the INFORMATION_SCHEMA.ROUTINES view should work in SQL Server 2000, 2005, and 2008. The only downside is that the view is no longer a viable means of determining the object's schema.
But if that is not a concern, try a script like this:
USE YourDB
GO
IF EXISTS (
SELECT *
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_NAME = 'usp_test'
) DROP PROCEDURE usp_test
GO
CREATE PROCEDURE usp_test AS
SELECT 1 AS val
GO
EXEC usp_test
GO
In most cases, I'd try to run SQL2000 TSQL on the 2005 box, as I'd expect it to be largely backward-compatible. That said, you ought to finish upgrading your production box so you can use newer TSQL.
In cases where you can't find compatibility between the versions, you could first detect the version.
To determine which version of SQL Server 2000/2005 is running, connect to SQL Server 2000/2005 by using Query Analyzer, and then run the following code:
SELECT
SERVERPROPERTY('productversion'),
SERVERPROPERTY ('productlevel'),
SERVERPROPERTY ('edition')
The results are:
The product version (for example, 8.00.534).
The product level (for example, “RTM” or “SP2″).
The edition (for example, “Standard Edition”).
For example, the result looks similar to:
8.00.534 RTM Standard Edition
Source: http://blog.sqlauthority.com/2007/03/07/sql-server-script-to-determine-which-version-of-sql-server-2000-2005-is-running/
Once you determine the version, you can execute the proper level of code.
The developer environment db server is SqlServer 2005 (developer edition)
Is there any way to make sure my SQL Queries will run in SqlServer 2000?
This database is set to Compatibility level "SQL Server 2000 (80)" but some queries that run without problems in the development system can not run in the Test Server (SqlServer).
(The problems seems to be in subqueries)
Compatibility levels are designed to work the opposite way - to allow an older version of T-SQL code to work without modifications on a newer version of SQL Server. The changes typically involve T-SQL syntax and reserved words, and it's possible to use SQL Server 2005 features such as INCLUDED columns in indexes on a database in Compatibility Level 80. However, you can't use 2005 T-SQL features such as CROSS APPLY.
Your best option is to develop/test all your code against a SQL Server 2000 instance. Note that you can use 2005's Management Studio to connect to the SQL Server 2000 instance, so you don't have to go backwards with regards to tools.
Problem solved:
In correlated subqueries you have to (in SQL2000) explicitly define the external field.
SQL2005:
SELECT * FROM Loans WHERE EXISTS (SELECT * FROM Collaterals WHERE COLLATERAL_LOAN=LOAN_NUMBER)
SQL2000:
SELECT * FROM Loans WHERE EXISTS (SELECT * FROM Collaterals WHERE COLLATERAL_LOAN=Loans.LOAN_NUMBER)
You should always explicitly define all fields, otherwise you will not get an error when you make a mistake and write
SELECT * FROM Loans WHERE EXISTS (SELECT * FROM Collaterals WHERE LOAN_NUMBER=Loans.LOAN_NUMBER)
If Collaterals-table doesn't have column LOAN_NUMBER, the Loans-table is used instead.