I need to query a table from another SQL Server on a different server but same domain, but I am not sure how I will be able to do it.
I tried solution given in this answer Can I create view in my database server from another database server but it doesn't work for me as I got SQL Server 2000 (please don't hate :-) ).
When I try solution given then i get this error,
Line 23: Incorrect syntax near '-'.
which is because command is not compatible with SQL Server 2000.
Edit
SELECT * FROM AnotherServer.AnotherServerDatabase.Server.Table1
you can link the servers and run cross server queries as long as you put the server name before the DB your running the query on.
For example
SELECT * FROM "linkedserver".dbo.aTable
(without "" marks )
bear in mind different server versions though. I run cross server queries from 2008 to 2000 servers and its a pain adapting :)
Is there a way (a tool) to check that a SQL Server 2008 script will run on SQL Server 2005?
Open up SQL Management studio, rt mouse click on the database name, select properties, select option, set compatability level. Test. A far as is known, when the compatabailty level is set to a (lower) level, functionality is disabled and errors raised entirely in line with the selected level. MS are a bit relctant to comit http://msdn.microsoft.com/en-gb/library/bb510680.aspx but in practice I've not found any issues. You can of course install an instance of the 2005 build and bulk insert for a really thorough check.
You can use SQL Fiddle for SQL Server 2008
At the left top you can select the RDMS
We need to execute a query on a SQL Server 2005 database to get some stats about the longest executions on it.
We've found the next query:
select top 10 source_code,stats.total_elapsed_time/1000000 as seconds,
last_execution_time from sys.dm_exec_query_stats as stats
cross apply
(SELECT text as source_code FROM sys.dm_exec_sql_text(sql_handle))
AS query_text
order by total_elapsed_time desc
It works fine, but it requires the database has a 90 compatibility level (SQL Server 2005). This database has a 80 level (SQL Server 2000). If we change it to 90... could it be dangerous to the daily tasks? I mean, could our applications crash if we change it?
Thank's and sorry for my English.
Finally I didn't need it. There was another database that had the 90 compatibility level and I used that one.
I never seen this, but is it possible to have one SQL call join data from Oracle and SQl Server?
Yes, Oracle and SQL Server both have functionality that allows to connect to other databases, including different vendors. In Oracle terminology, it's a database link instance while on SQL Server it's called a Linked Server instance.
The syntax to reference the instance is different between Oracle and SQL Server though. IE:
Oracle:
SELECT t.*
FROM table_name#database_link_instance t
SQL Server:
SELECT t.*
FROM linked_server_instance_name.database_name.schema_name.table_name t
does MySQL support the linked server concept?
No, the closest MySQL has is the FEDERATED engine, which is only for connecting to remote MySQL instances.
PostgreSQL?
PostgreSQL has dblink. Last time I looked at dblink (pre-v9 release), it only could connect to other PostgreSQL instances.
Yes- both Oracle and SQL Server support the linked server concept. That allows you to reference the other server using a 4 part name. For example:
select *
from LocalDb.Schema.Table
cross join
OracleLinkedServer.RemoteDb.RemoteSchema.RemoteTable
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.