怎么实现网页和数据库(SQL)的连接(网页制作连接sql数据库)

sqlserver

2000无论是个人版、企业版还是标准版，只要细版本在8001760以下，均不提供远程数据库连接，即使服务器端工具和客户端工具的设置均有tcp/ip设置和数据库连接属性也设置了rpc远程连接，仍然不能实现远程连接。该怎么解决呢？

解决方案如下：

首先，需要打sp4补丁，该补丁包含了以前sp1、2、3的补丁，安装此补丁后一般要重新启动计算机，再进行远程连接就可以了，如再企业管理器可远程注册服务器、查询分析可连接远程服务器、odbc可连接远程服务器。

要点：

1确认服务器端sql服务端口号是否为：1433

2如果不是1433，配置客户端

3建立服务器端登录帐号，确保角色及管理数据库

一、查看服务器端情况

1

看ping

服务器ip能否ping通。

这个实际上是看和远程sql

server

服务器的物理连接是否存在。如果不行，请检查网络，查看配置，当然得确保远程sql

server

服务器的ip拼写正确。

2

在dos或命令行下输入telnet

服务器ip

端口，看能否连通。

如telnet

202114100100

1433

通常端口值是1433，因为1433是sql

server

的对于tcp/ip的默认侦听端口。如果有问题，通常这一步会出问题。通常的提示是“无法打开连接,连接失败"。

如果这一步有问题，应该检查以下选项。

1)

检查远程服务器是否启动了sql

server

服务。如果没有，则启动。

2)

检查sql

server服务器端有没启用tcp/ip协议，因为远程连接(通过因特网)需要靠这个协议。检查方法是，在服务器上打开

开始菜单->程序->microsoft

sql

server->服务器网络实用工具，看启用的协议里是否有tcp/ip协议，如果没有，则启用它。

3)

检查服务器的tcp/ip端口是否配置为1433端口。仍然在服务器网络实用工具里查看启用协议里面的tcp/ip的属性，确保默认端口为1433，并且隐藏服务器复选框没有勾上。

事实上，如果默认端口被修改，也是可以的，但是在客户端做telnet测试时，写服务器端口号时必须与服务器配置的端口号保持一致。如果隐藏sql

server服务器复选框被勾选，则意味着客户端无法通过枚举服务器来看到这台服务器，起到了保护的作用，但不影响连接，但是tcp/ip协议的默认端口将被隐式修改为2433，在客户端连接时必须作相应的改变(具体方式见

二：设置客户端网络实用工具)。

4)

如果服务器端 *** 作系统打过sp2补丁，则要对windows防火墙作一定的配置，要对它开放1433端口，通常在测试时可以直接关掉windows防火墙(其他的防火墙也关掉最好)。(4、5步我没有做就成功了)

5)

检查服务器是否在1433端口侦听。如果sql

server服务器没有在tcp连接的1433端口侦听，则是连接不上的。检查方法是在服务器的dos或命令行下面输入

netstat

-a

-n

或者是netstat

-an，在结果列表里看是否有类似

tcp

127001

1433

listening

的项。如果没有，则通常需要给sql

server

2000打上至少sp3的补丁。其实在服务器端启动查询分析器，输入select

@@version

执行后可以看到版本号，版本号在802039以下的都需要打补丁。

如果以上都没问题，这时你再做telnet

服务器ip

1433

测试，将会看到屏幕一闪之后光标在左上角不停闪动。恭喜你，你马上可以开始在企业管理器或查询分析器连接了。

测试应该看服务器日志。
在日常测试中，我们常常会遇到页面上出现不易理解或不正常的报错，而日志中会记录错误原因以及其他各种信息。一般我们可以去问开发也可以自己找原因。
查看服务器日志最简单的方式就是在终端 *** 作。步骤如下：①打开终端，②输入ssh 用户名@ip地址(如：ssh user@172182410)。一般公司会有一个服务器配置文档，里面有用户、ip地址和密码等信息。③输入密码。密码不会显示，直接输入即可。④用cd命令进入到相应的日志目录中。这个目录路径可以问测试或开发。⑤用tail -f -n 1000 xxxlog 查看对应的日志文件。这个和报错对应的日志可以问测试或开发。tail命令是指显示日志文档最后1000行。

在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？

对于测试结果的分析，我们通常观察下面几种情况。

观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行 *** 作，观察返回结果是否符合业务方的需求预期；第二， *** 作后端的服务器（通常是重启、宕机、断网等 *** 作），观察前端应用的返回结果是否符合系统的设计需求。

分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定义为Debug级别（最低级别）。这样做的主要目的是为了能便于测试工程师来分析日志和定位问题。为了能更好地定位问题，常常需要在服务器程序代码中进行日志打桩，把程序中的一些重要数据通过日志的方式展现出来。通常情况下，我们需要对日志的格式进行约定，在日志行中增加一些关键字来进行分类，这将便于测试工程师进行日志分析，也有利于开展分布式系统的自动化测试。另外，值得注意的是，我们尽可能地将打桩代码放在Debug代码中，避免影响系统代码，引入新问题。

分析 *** 作系统的一些重要信息。我们测试的分布式系统绝大多数是基于Linux *** 作系统开发的，在测试的过程中，除了详细分析程序日志以外，还需要对 *** 作系统的一些重要数据信息进行分析，从而来诊断服务器程序是否存在异常。以Linux *** 作系统为例，我们常常会使用top命令、netstat命令及sar命令来查看 *** 作系统的一些数据信息。例如，可以通过netstat命令检查服务器程序是否正确地监听了指定的端口等。

借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于内存检测工具来进行分析。在Linux环境下，我们常用Valgrind来进行内存检测。这是一款非常好用、功能强大的分析工具，可以帮助测试或者开发工程师快速发现很多隐藏的程序Bug，尤其是在内存检测方面（同时它还具有很多其他优秀的功能，读者可以自己查看官网中的使用手册）。对于分布式系统而言，压力测试和性能测试非常重要。在进行压力测试和性能测试的时候，可能会碰到下面一些难点。

数据准备。如何准备海量的测试数据并保证模拟数据的真实性？以一个分布式的文件系统为例，预先存入100GB的数据还是存入100TB的数据、存入的文件是大小基本一致差别不大还是各不相同甚至差异很大（例如，从几十字节至几十兆字节不等），这些因素对于分布式系统的性能影响是有很大差异的。另外，如果需要预先存入100TB的数据，若按每秒写入100MB数据来计算，写入100TB数据需要100×1024×1024/100=1048576秒=29127小时=12天。我们是否能忍受这么长时间的数据准备工作？为了解决这样的问题，我们需要对系统架构设计进行深入分析，设计好测试场景，并提前进行测试用例的设计，以尽早开始准备测试数据。

性能或压力测试工具。通常来说，分布式系统的测试需要开发一些测试工具来满足性能测试的需求。如果可以的话，建议这样的测试工具最好由测试工程师自己来实现，因为测试工程师更清楚自己的测试需求。当需要自己开发测试工具的时候，有两个关键问题需要重点关注：第一，一些关键数据的收集方式与计算将成为性能测试工具的关键，例如，TPS（每秒请求数）、Throughput（吞吐量）计算的准确性；第二，要保证性能测试工具的性能，如果工具本身的性能不好，将无法给予分布式系统足够强大的压力来进行测试。另外，当考虑到多并发（例如有10万客户端同时并发连接）时，如果性能测试工具在一台测试机器上只能运行50个或者更少的话，那么需要的测试机器数量也将会很庞大（例如2000台测试机），这个成本或许是许多公司不能承受的。因此，性能测试工具本身的性能必须要足够好才能满足需求、降低测试成本。自动化测试是测试行业发展的必然趋势，对于分布式系统测试而言也不例外。在实施分布式系统自动化测试的过程中，我们可能会碰到下面两个难点问题。

涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需要控制的 *** 作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网络设备。因此，选择一个优秀的自动化测试框架成为了非常重要的工作之一。以我们的实践经验来看，STAF是一个不错的选择，它的平台（Windows及Linux各版本）支持及开发语言的支持都很全面。

测试结果验证复杂。对于分布式系统的自动化测试来说，我们需要通过测试脚本来收集各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。例如，我们会设计一个日志分析模块，主要负责从服务器应用程序的日志中收集相应数据进行对比验证（本文前面提到的在打桩日志中增加关键字部分就显得格外重要）。

随着互联网的发展，大型分布式系统也越来越多、越来越复杂、越来越重要。如何有效地保证大型分布式系统7×24小时全天候持续稳定地运行也就成为了一个重要课题。

官方的客户端测试工具
>