Opening Firewall for SQL Server allowing TCP access

From Microsoft TechNext

When you can't access a remote sql server, always change the firewall 1st.
the confirm what the sa / user password.

To open a port in the Windows firewall for TCP access

1. On the Start menu, click Run, type WF.msc, and then click OK.
2. In the Windows Firewall with Advanced Security, in the left pane, right-click Inbound Rules, and then click New Rule in the action pane.
3. In the Rule Type dialog box, select Port, and then click Next.
4. In the Protocol and Ports dialog box, select TCP. Select Specific local ports, and then type the port number of the instance of the Database Engine, such as 1433 for the default instance. Click Next.
5. In the Action dialog box, select Allow the connection, and then click Next.
6. In the Profile dialog box, select any profiles that describe the computer connection environment when you want to connect to the Database Engine, and then click Next.
7. In the Name dialog box, type a name and description for this rule, and then click Finish.

Using BCP utility

Bulk copy program bcp is still supported by SQL 2008 R2 and SQL 2012 Yeah!!!

SQL 2008 R2 http://technet.microsoft.com/en-us/library/ms162802(v=sql.105).aspx
The bcp 10.0 client is installed when you install Microsoft SQL Server 2008 R2 tools. If tools are installed for both SQL Server 2008 R2 and SQL Server 2005, depending on the value of the PATH environment variable, you might be using the earlier bcp client instead of the bcp 10.0 client. This environment variable defines the set of directories used by Windows to search for executable files. To discover which version you are using, run the bcp /v command at the Windows Command Prompt. For information about how to set the command path in the PATH environment variable, see Windows Help.

SQL 2012 http://technet.microsoft.com/en-us/library/ms162802.aspx
The bcp 11.0 client is installed when you install Microsoft SQL Server 2012 tools. If tools are installed for both SQL Server 2012 and an earlier version of SQL Server, depending on the value of the PATH environment variable, you might be using the earlier bcp client instead of the bcp 11.0 client. This environment variable defines the set of directories used by Windows to search for executable files. To discover which version you are using, run the bcp /v command at the Windows Command Prompt. For information about how to set the command path in the PATH environment variable, see Windows Help.

For exporting

bcp [database name].dbo.[table name] out  -n -S -U -P

For Import

bcp [database name].dbo.[table name] out  -n -S -U -P


case is important on arguments.  -n is very important. forces bcp to sql native format.  This is essential of you are exporting and importing data to tables to prevent truncating.

Example

Bcp [New410].dbo.tbCPTDx out tbCPTDx.bcp –n –SRISQA2008R2 –Usa –Psa

Link servers from SQL 2008 R2 to SQL 2000 (32bit)

Solutiion is from http://sqlblog.com/blogs/roman_rehak/archive/2009/05/10/issue-with-64-bit-sql-server-using-sql-2000-linked-server.aspx

Issue with 64-bit SQL Server using SQL 2000 linked server

Recently we started adding SQL Server 2008 64-bit servers to our production set and we ran into the following issue. When we ran queries on a linked 2000 server, we were getting the following error:
OLE DB provider "SQLNCLI10" for linked server "XXXXXX" returned message "The stored procedure required to complete this operation could not be found on the server. Please contact your system administrator.".
Msg 7311, Level 16, State 2, Line 1
Cannot obtain the schema rowset "DBSCHEMA_TABLES_INFO" for OLE DB provider "SQLNCLI10" for linked server "XXXXXX". The provider supports the interface, but returns a failure code when it is used.
This article from MS website describes the issue pretty well, although it says the issue applies to 2005 but we are using 2008. As suggested, we ran the Instcat.sql file on our development system first, and we ended up getting errrors left and right, so we didn't dare to run it on our main production server. In the end, this workaround worked for us - we needed to create a procedure in the master database on the linked 2000 server. The proc is called sp_tables_info_rowset_64 and it is needed because it is called by 64-bit servers when running remote queries.
 Here is the text of the proc in case you ever need to do the same, create it in the master database:

create procedure sp_tables_info_rowset_64

      @table_name sysname,

      @table_schema     sysname = null,  

      @table_type nvarchar(255) = null

as

  declare @Result int set @Result = 0

  exec @Result = sp_tables_info_rowset @table_name, @table_schema, @table_type
go