sql 怎么都连接不上服务器

1、转到[Microsoft SQL Server 2008]并找到[SQL Server配置管理器]，单击里面。

2、我们选择单击[QL服务器网络配置]。

3、我们选择禁用[TCP / IP]并启用它。

4、框中的几个选项的状态应为[正在运行]。

5、之后跳出一个页面这是对启动过程的提醒。

6、确保这些项目处于[Running]状态。

7、然后单击SQL Server 2008中的连接。

8、之后它可以连接到服务器。效果如下。

你问的问题就有点毛病，mysql与sql server 2000之间如何创建连接服务器？，mysql与sql server 2000本身就在服务器上，应该是程序或应用软件然后链接mysql与sql server 2000；或者是如何管理mysql与sql server 2000，
MYSQL 可以用PHP的phpmyadmin或桌面软件Navicat for MySQL，sql server 微软本就又管理器SQL Server Management Studio Express，你可以去微软网站上搜索下。

你问的问题就有点毛病，mysql与sql
server
2000之间如何创建连接服务器？，mysql与sql
server
2000本身就在服务器上，应该是程序或应用软件然后链接mysql与sql
server
2000；或者是如何管理mysql与sql
server
2000，
MYSQL
可以用PHP的phpmyadmin或桌面软件Navicat
for
MySQL，sql
server
微软本就又管理器SQL
Server
Management
Studio
Express，你可以去微软网站上搜索下。

遇到下列问题：
线上服务器A，中转服务器B，本地服务器C
数据在A上面，想在B上面 *** 作类似 select from [A][database]table这样的SQL，不用去链接服务器，直接把处理结果导入B然后生成报表。
结果报错如下：
消息 7202，级别 11，状态 2，第 1 行
在 sysservers 中找不到服务器 'A'。请验证指定的服务器名称是否正确。如果需要，请执行存储过程 sp_addlinkedserver 以将服务器添加到 sysservers。
执行下面 *** 作在B服务器上面创建A服务器连接，
step1：服务器地址（IP），服务器类型，访问借口
step2:用户设置、安全设置。
注意上面的本地登录用户和远程用户名，注意最下面的使用此安全上下文建立连接。输入用户名密码。服务器选项设为默认可以。
OK 再次执行select from [A][database]table 数据展现正常，问题解决。

引言

该堆栈的顶部是 API 或对象库层 应用程序通过对象库公开的 API 函数或接口连接到 Microsoft SQL Server 用于访问 SQL Server 的 API 示例包括 ODBC 和 DB Library 用于访问 SQL Server 的对象库示例包括 OLE DB ADO 和 ADO NET 由于 ADO 最终使用 OLE DB 与服务器通信 因此 Windows 应用程序在与 SQL Server 通信时实际上只使用两个常用的对象库 即 OLE DB 和 ADO NET 由于通过 ADO 或 ADO NET 进行连接通常比通过 ODBC 进行连接更普遍(但 SQL Server 的查询分析器和企业管理器仍通过 ODBC 进行连接) 因此本文将从 ADO/OLE DB 和 ADO NET 的角度介绍 SQL Server 连接体系结构的客户端 如今 大多数应用程序均通过对象库(而非 ODBC 或类似 API)连接到 SQL Server

ADO 和 OLE DB

OLE DB 客户端(也称作使用者)通过客户端提供程序与服务器以及其他后端程序进行通信 此提供程序是一组 组件(一个或多个) 用于将应用程序请求转换为网络进程间通信 (IPC) 请求 在使用 SQL Server 的情况下 最常用的 OLE DB 提供程序是 SQLOLEDB 它是 Microsoft 为 SQL Server 提供的 OLE DB 提供程序 SQLOLEDB 随附于 SQL Server 中 并作为 Microsoft 数据访问组件 (MDAC) 库的一部分安装

为了使用 ADO 与 SQL Server 进行通信 应用程序首先使用 Connection 对象建立与服务器的连接 ADO 的 Connection 对象接受一个连接字符串 该字符串指定要使用的 OLE DB 提供程序以及传递给它的参数 如果应用程序使用 SQLOLEDB 提供程序连接到 SQL Server 则该字符串中将显示 SQLOLEDB

ADO 应用程序还可以通过 ODBC 连接到 SQL Server 为此 应用程序将使用适用于 ODBC 的 OLE DB 提供程序 并指定在其连接字符串中引用目标 SQL Server 的 ODBC 数据源 这种情况下 应用程序与 OLE DB 进行通信 同时 ODBC 的 OLE DB 提供程序调用相应的 ODBC API 以便与 SQL Server 进行会话

ADO NET

ADO NET 应用程序通常使用 NET Framework Data Provider for SQL Server 连接到 SQL Server 该本机提供程序使 ADO NET 对象能够与 SQL Server 直接进行通信 通常 应用程序使用 SqlConnection 对象建立连接 然后使用 SqlCommand 对象向服务器发送命令 并接收服务器返回的结果 SqlDataAdapter 和 SqlDataReader 类通常与 SqlCommand 一起使用 以便通过托管的代码应用程序与 SQL Server 进行交互

通过 OleDbConnection 类 ADO NET 应用程序还可以使用 SQLOLEDB OLE DB 提供程序与 SQL Server 进行交互 此外 它们可以通过 OdbcConnection 类使用 ODBC 访问 SQL Server 因此 仅通过托管代码 您就有三种不同的方法从应用程序访问 SQL Server 从故障排除的角度而言 了解这些方法是非常有用的 因为它可以帮助您将遇到的与连接相关的问题归结到特定的数据访问层或库

客户端 Net Library

该堆栈中的下一层是 Net Library Net Library 在 API 或对象库(应用程序使用它与 SQL Server 进行通信)与网络协议(用于与网络交换数据)之间提供了一个通道 SQL Server 为所有主要的网络协议提供了 Net Library 这些库以透明方式将客户端发出的请求发送到 SQL Server 并将服务器发出的响应返回给客户端 可以使用 SQL Server 的客户端网络实用程序配置适用于特定客户端的 Net Library 支持的客户端协议包括 TCP/IP 命名管道 NWLink 多协议 (RPC) 和其他一些协议

尤其值得一提的 Net Library 是共享内存 Net Library 顾名思义 该 Net Library 使用 Windows 的共享内存功能在 SQL Server 客户端与服务器之间进行通信 显然 这意味着客户端与服务器必须位于同一台物理计算机上

由于它能够绕过物理网络堆栈 因此共享内存 Net Library 要比其他 Net Library 快得多 对共享内存区域的访问受到同步对象的保护 因此客户端与服务器之间的通信速度主要受限于 Windows 对内核对象进行调度的能力 以及进程与共享内存区域之间进行数据复制的能力

可以在连接时将某个时间段或(本地)指定为您的计算机名 来指示使用共享内存 Net Library 也可以在连接时为计算机\实例名加上前缀 lpc: 来指示要使用共享内存 Net Library

注意 即使连接到同一台计算机上的 SQL Server 共享内存 Net Library 也未必就是最佳的连接选项 在某些情况下 客户端与服务器之间的直接连接可能限制它的扩展性 与应用程序整体体系结构中的其他元素一样 应始终对给定技术解决方案进行全面的测试 然后才能判断它是否有良好的扩展性以及是否比其他方法更快

连接

客户端进行连接时 SQL Server 的用户模式计划程序 (UMS) 组件将它指定给特定的计划程序 启动时 SQL Server 为系统上的每个 CPU 创建一个单独的 UMS 计划程序 当客户端连接到服务器时 这些客户端将指定给具有最少连接数的计划程序 连接后 客户端将不会更换计划程序 它将始终受到指定计划程序的控制 直到连接断开

这对与服务器建立多个连接的应用程序很重要 如果应用程序性能较差 或无法在它的多个连接上平均分配工作 则在该应用程序的某些连接之间可能造成不必要的 CPU 资源争用 而其他连接实际上却处于空闲状态

例如 应用程序与双处理器计算机上运行的 SQL Server 建立了四个连接 连接 和 隶属于处理器 连接 和 隶属于处理器 如果应用程序的大部分工作通过连接 和 执行 则这两个连接将争用 CPU 而 CPU 实际上可能仍处于空闲状态 这种情况下 应用程序只能断开某些连接或重新连接某些连接 并希望连接 和 隶属于不同的 CPU (连接时无法指定处理器隶属关系) 或在它的连接上重新分配工作负荷 以便每个连接的工作负荷更加均衡 当然 后一种情况要远好于前一种情况

连接内存

SQL Server 为客户端请求的每个连接保留三个数据包缓冲区 每个缓冲区的大小取决于 sp_configure 存储过程指定的默认网络数据包大小 如果默认网络数据包大小小于 KB 则这些数据包的内存将由 SQL Server 的缓冲池提供 否则 该内存将由 SQL Server 的 MemToLeave 区域分配

值得一提的是 NET Framework Data Provider for SQL Server 的默认网络数据包大小为 KB 因此 与托管代码客户端连接关联的缓冲区通常由 SQL Server 的 MemToLeave 区域提供 而典型的 ADO 应用程序却不同 它们的默认数据包大小为 KB 因此缓冲区将由 SQL Server 缓冲池分配

事件

连接后的客户端请求通常分为两种广泛类别 语言事件和远程过程调用 尽管还存在其他类别 但大多数由 SQL Server 客户端发送到服务器的请求由以下两种类型之一构成 语言事件是从客户端发送到服务器的 一组 T SQL 例如 如果调用 ADO Command 对象(其 CommandText 属性设置为 T SQL 查询 CommandType 属性设置为 adCmdText)的 Execute 方法 则查询将作为语言事件提交给服务器 同样 如果将 CommandType 设置为 adCmdTable 并调用 Execute 方法 则 ADO 将生成一个内部查询(它将选择 CommandText 属性标识的表中的所有列) 并将它作为语言事件提交给服务器 另一方面 如果将 CommandType 设置为 adStoredProc 则调用 Execute 将使 ADO 向服务器提交一个远程过程调用请求 以执行 CommandText 属性中列出的存储过程

为何要关心将请求作为语言事件还是作为 RPC 提交给服务器呢通常 这是因为 RPC 的功能更为出色 特别是在重复调用具有不同筛选值的同一查询时 尽管 SQL Server 可以自动将普通的语言事件请求参数化 但这种能力非常有限 它从不尝试自动将某些类型的查询参数化 这可能会导致基本相同的查询产生不同的执行 从而只因为这些不同的执行提供不同的值 而导致在服务器上白白浪费计划编译的成本 这通常不是您所希望的结果 您希望针对查询的第一次执行编译一个新的计划 然后将该计划重复用于具有不同参数的执行

而 RPC 则通过显式参数化查询(而不是依赖服务器参数化查询)来支持计划重复使用 为过程的第一次执行生成一个计划后 随后的执行将自动重复使用该计划 即使它们提供的参数值不同 与通过语言事件调用存储过程相比 使用 RPC 调用存储过程不仅节省了计划编译所需的执行时间和 CPU 资源 还增强了 SQL Server 内存资源的利用率 因为它避免了冗余执行计划所浪费的内存

在执行动态 T SQL 时 通常首选 sp_executesql 而不是 EXEC() 也出于同样的原因 Sp_executesql 的工作方式是 使用指定的查询创建一个存储过程 然后使用提供的参数调用它 与 EXEC() 不同 sp_executesql 提供了一个允许您参数化动态 T SQL 并支持计划重复使用的机制 使用 sp_executesql 执行的动态查询比使用 EXEC() 的查询能够在更大程度上避免不必要的编译和资源消耗

TDS

从客户端发送到 SQL Server 的 RPC 语言事件和其他类型的请求被格式化为称作表格数据流 (TDS) 的 SQL Server 特定数据格式 TDS 是 SQL Server 客户端和服务器之间使用的 语言 对于它的确切格式将不作介绍 但是 如果客户端要与 SQL Server 进行通信 就必须使用 TDS

目前 SQL Server 支持三种版本的 TDS TDS (适用于 SQL 客户端) TDS (适用于 SQL Server 客户端)和 TDS (适用于 SQL Server 和 客户端) 完全支持所有 SQL Server 功能的版本只有 TDS 其他版本保持向后兼容

服务器端 Net Library

---