请检查数据库连接字符串设置是否正确或数据库服务器身份验证模式是否SQL Server和

修改数据库身份模式的验证

解决方法如下,打Microsoft Sql Server Management Studio Express,以windows验证方式登陆,打开服务器属性窗口(在数据库服务器图标上点右键选"属性"),选择"安全性"选项,

服务器验证方式选择SQL SERVERTT和windows验证方式,确认

然后再到"安全性-登陆名"处设置SA用户属性,

设置密码

解决方法：打开“开始—所有程序—Microsoft SQL Server 2005 —配置工具—SQL Server 配置管理器”，在d出的窗体中，找到“SQL Server 2005 网络配置”，把“MSSQLSERVER的协议”下的“Named Pipes”和“TCP/IP”启用，然后重新启动SQL Server 即可。

数据库一致性检查(dbcc)提供了一些命令用于检查数据库的逻辑和物理一致性。Dbcc主要有两个功能：

使用checkstorage 或 checktable 及 checkdb 在页一级和行一级检查页链及数据指针。

使用checkstorage, checkalloc, 或 checkverify, tablealloc, 及indexalloc

检查页分配。

在下列情况中需要使用 dbcc 命令： 作为数据库日常维护工作的一部分, 数据库内部结构的完整性决定于sa 或dbo 定期地运行

dbcc 检查。 在系统报错以后, 确定数据库是否有损坏。 在备份数据库之前, 确保备份的完整性。 如果怀疑数据库有损坏时, 例如,

使用某个表时报出表损坏的信息, 可以使用 dbcc 确定数据库中其他表是否也有损坏。

下面是dbcc的简单用法： dbcc checktable (table_name) 检查指定的表,

检查索引和数据页是否正确链接, 索引是否正确排序, 所有指针是否一致, 每页的数据信息是否合理, 页偏移是否合理。 dbcc

checkdb (database_name) 对指定数据库的所有表做和checktable 一样的检查。 dbcc

checkalloc (database_name,fix|nofix) 检查指定数据库, 是否所有页面被正确分配,

是否被分配的页面没被使用。当使用"fix"选项时，在检查数据库的同时会自动修复有问题的页面。（若数据库数据量很大，则该过程会持续很长时间。）

dbcc tablealloc (table_name,fix|nofix) 检查指定的表, 是否所有页面被正确分配,

是否被分配的页面没被使用。是 checkalloc 的缩小版本,

对指定的表做完整性检查。当使用"fix"选项时，在检查数据表的同时会自动修复数据表中有问题的页面。

关于上述命令的其它选项及详细使用方法和checkstorage, checkverify, indexalloc

的详细使用方法, 请参阅有关命令手册。 举例1： Unix平台检查pubs2数据库的一致性 单用户模式启动Server：

$SYBASE/install startserver -f RUN_server_name -m

vi dbcc_dbsqluse mastergosp_dboption pubs2,"single user",truegouse pubs2gocheckpoint go dbcc checkdb(pubs2)godbcc checkalloc(pubs2,fix)godbcc checkcatalog(pubs2)gouse mastergosp_dboption pubs2,"single user",falsegouse pubs2gocheckpointgoquit go isql -Usa -Pxxxxxx -SSYBASE dbcc_dbout

grep Msg dbcc_dbout

举例2： Unix平台检查pubs2数据库中titles表的一致性

具体情况请说明下，是第一次安装后启动出现的这种情况，还是用了一段时间突然出现这种情况。还是本机可以连接，其他机子无法连接？

首先确认数据库是不是正常启动了，然后

如果是第一次安装，你的 *** 作系统是什么？vista和win7装sql2000不一定能装上，需要2005，而且如果是win7家庭版很可能出现数据库和软件连不上。如果是xp，以前是不是装过数据库后来卸载了，那么卸掉sql清除干净注册表，重新安装sql，最好用完整版，不要使用msde。

如果是用了一段时间，很可能是杀毒软件误杀数据库文件，卸掉杀毒软件，在管理里面启动下数据库，看能否启动，如果还能启动。再启动速达看能否连接上。如果数据库已经无法启动，将数据作出备份，重装数据库吧。

如果是本机连接没问题，其他连不上的话，关闭服务器和客户端window自带防火墙，数据库打sp4补丁，开启guest用户，试下。

可以使用语句检查表。如果结果的msg_text部分是好的，那么你的表是健康的。反之，则表明mysql数据库中的表有损坏。另外有些厉害的高手一额可以通过运行脚本来检测。

MyISAM 表可以采用以下方法进行修复 ：使用 reapair table 或myisamchk 来修复。如果修复无效，采用备份恢复表。

阶段1 ：检查你的表

如果你有很多时间，运行myisamchk MYI 或myisamchk -e MYI 。使用-s （沉默）选项禁止不必要的信息。如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。

你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段2 ：简单安全的修复

注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。

首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：

在继续前对数据文件进行备份。使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。

如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段3 ：困难的修复

只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤 *** 做：

把数据文件移到安全的地方。使用表描述文件创建新的( 空) 数据文件和索引文件：

shell> mysql db_name

mysql> SET AUTOCOMMIT=1;

mysql> TRUNCATE TABLE tbl_name;

mysql> quit

如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。将老的数据文件拷贝到新创建的数据文件之中。回到阶段2 。现在myisamchk -r -q 应该工作了。你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。

阶段4 ：非常困难的修复

只有frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。

从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。

如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让MYD 数据文件独自留下来了。回到阶段2并且尝试重建索引文件。

检查一下数据库服务有没有启动，找到Firebird Server服务，如果是未启动，把他启动，而且要把服务设成自启动，不然下次重启机器又连不到了，系统要正常打开，数据库服务一定要运行状态

以上就是关于请检查数据库连接字符串设置是否正确或数据库服务器身份验证模式是否SQL Server和全部的内容，包括:请检查数据库连接字符串设置是否正确或数据库服务器身份验证模式是否SQL Server和、如何检查数据库中数据的一致性、打开软件时，系统出现“无法连接数据库，请检查SQL服务器是否启动或网络是否正常”这样的错误提示。等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！