分类目录归档:DB

数据库

SQL Server超过了每行的最大字节数(8060)的原因和解决办法

今天朋友碰到这个问题,好像说过很多遍了,那就发布出来以免每次都说。
一、现象
一般出现这种现象都是适用sql文件在查询分析器里建库的时候,现象一般都是提示:

“警告: 已创建表 ‘XXXX,但其最大行大小(89960)超过了每行的最大字节数(8060)。如果结果行长度超过 8060 字节,则此表中行的 INSERT 或 UPDATE 将失败。”

已创建表 ‘xxxx’,但其最大行大小(10438)超过了每行的最大字节数(8060)。如果结果行长度超过 8060 字节,则此表中行的INSERT 或 UPDATE 将失败。      其中xxxx是你的建的表名,10438是你建表语句中可变长度列(如 nvarchar 或varbinary)的总长度,8060是SQL Server对行长度的最大限制。
二、原因
其实把上面三个概念搞清楚,警告的原因就应该清楚了,就是因为你的建表语句中可变长度列的总长度超过了SQLServer对行最大长度的限制8060。如果每一行中数据的总长度不超过8060 字节,就仍可以向表中插入行。但是如果数据超过8060字节,因此系统提示你就会出现插入或更新操作失败。
错误提示:
服务器:信息 511,级别 16,状态 1,第 5 行
无法创建大小为 的行,该值大于允许的最大值 8060。
语句已终止。     举个例子:比如我总共有10块钱,买A东西可能花1-5块,买B东西可能花2-3块,买C东西可能花3-6块,那我在做预算的时候就要提醒自己,如果ABC三个东西都要花上限的钱,那我的钱可就不够了,因为5+3+6=14 >10,虽然可能我只花了1+2+3=6块钱就把ABC全买了。
三、解决
知道问题的原因了,解决办法相对就简单了!
1、修改你建表语句中相应的列的数据类型或长度(如将nvarchar格式改成text),让可变长度列的加和小于8060。这样可以彻底避免出现上述错误发生,当然上述的错误并不是必然出现。
2、在绝大多数情况下不会出现各列长度超过行限制的时候(这个需要根据存储的数据的情况自行判断),你也可以忽略这个提示,这并不会必然影响到你正常的操作。
四、SQL Server数据详解

bit 数据类型是整型,其值只能是0、1或空值。这种数据类型用于存储只有两种可能值的数据,如Yes 或No、True 或False、On 或

int 数据类型可以存储从到之间的整数。存储到数据库的几乎所有数值型的数据都可以用这种数据类型。这种数据类型在数据库里占用4个字节

smallint 数据类型可以存储从到之间的整数。这种数据类型对存储一些常限定在特定范围内的数值型数据非常有用。这种数据类型在数据库里占用2 字节空间

tinyint 数据类型能存储从0到255 之间的整数。它在你只打算存储有限数目的数值时很有用。 这种数据类型在数据库中占用1 个字节

decimal 数据类型能用来存储从到的固定精度和范围的数值型数据。使用这种数据类型时,必须指定范围和精度。 范围是小数点左右所能存储的数字的总位数。精度是小数点右边存储的数字的位数

money 数据类型用来表示钱和货币值。这种数据类型能存储从-9220亿到9220 亿之间的数据,精确到货币单位的万分之一

smallmoney 数据类型用来表示钱和货币值。这种数据类型能存储从-214748.3648 到214748.3647 之间的数据,精确到货币单位的万分之一

float 数据类型是一种近似数值类型,供浮点数使用。说浮点数是近似的,是因为在其范围内不是所有的数都能精确表示。浮点数可以是从-1.79E+308到1.79E+308 之间的任意数

real 数据类型像浮点数一样,是近似数值类型。它可以表示数值在-3.40E+38到3.40E+38之间的浮点数

datetime数据类型用来表示日期和时间。这种数据类型存储从到9999年12月3 1日间所有的日期和时间数据, 精确到三百分之一秒或3.33毫秒

smalldatetime 数据类型用来表示从到间的日期和时间,精确到一分钟

cursor 数据类型是一种特殊的数据类型,它包含一个对游标的引用。这种数据类型用在存储过程中,而且创建表时不能用

timestamp 数据类型是一种特殊的数据类型,用来创建一个数据库范围内的唯一数码。一个表中只能有一个timestamp列。每次插入或修改一行时,timestamp列的值都会改变。尽管它的名字中有“time”,但timestamp列不是人们可识别的日期。在一个数据库里,timestamp值是唯一的

Uniqueidentifier数据类型用来存储一个全局唯一标识符,即GUID。GUID确实是全局唯一的。这个数几乎没有机会在另一个系统中被重建。可以使用NEWID 函数或转换一个字符串为唯一标识符来初始化具有唯一标识符的列

char数据类型用来存储指定长度的定长非统一编码型的数据。当定义一列为此类型时,你必须指定列长。当你总能知道要存储的数据的长度时,此数据类型很有用。例如,当你按邮政编码加4个字符格式来存储数据时,你知道总要用到108000 个字符

varchar数据类型,同charchar 型不一样,此数据类型为变长。当定义一列为该数据类型时,你要指定该列的最大长度。 它与char数据类型最大的区别是,存储的长度不是列长,而是数据的长度

text 数据类型用来存储大量的非统一编码型字符数据。这种数据类型最多可以有或20亿个字符

nchar 数据类型用来存储定长统一编码字符型数据。统一编码用双字节结构来存储每个字符,而不是用单字节(普通文本中的情况)。它允许大量的扩展字符。此数据类型能存储4000种字符,使用的字节空间上增加了一倍

nvarchar 数据类型用作变长的统一编码字符型数据。此数据类型能存储4000种字符,使用的字节空间增加了一倍

ntext 数据类型用来存储大量的统一编码字符型数据。这种数据类型能存储或将近10亿个字符,且使用的字节空间增加了一倍

binary数据类型用来存储可达8000 字节长的定长的二进制数据。当输入表的内容接近相同的长度时,你应该使用这种数据类型

varbinary 数据类型用来存储可达8000 字节长的变长的二进制数据。当输入表的内容大小可变时,你应该使用这种数据类型

image 数据类型用来存储变长的二进制数据,最大可达或大约20亿字节

五、SQL Server引用的各种对象的最大值
下表说明在 Microsoft SQL Server 数据库中定义的,或在 Transact-SQL 语句中引用的各种对象的最大值(数量或大小)。下表不包含 Microsoft SQL Server 2000 Windows CE 版。
每个 SQL Server 实例的锁数2,147,483,647(或可用内存)2,147,483,647(或可用内存)     1、网络数据包大小是表格格式数据方案 (TDS) 数据包的大小,该数据包用于应用程序和关系数据库引擎之间的通讯。默认的数据包大小为 4KB,由 network packet size 配置选项控制。
2、在 SQL Server 2000 中,任何键的最大字节数不能超过 900。可以使用可变长度的列来定义键,只要在这种列中不插入数据超过 900 字节的行,其最大大小就可以在 900 以上。有关更多信息,请参见索引键的最大值。
3、当使用 SQL Server 2000 Desktop Engine 或 Microsoft 数据引擎 (MSDE) 1.0 时,数据库的大小不能超过 2 GB。
4、数据库对象包括所有的表、视图、存储过程、扩展存储过程、触发器、规则、默认值及约束。一个数据库中所有对象的总数不得超过 2,147,483,647。
六、其它
其他关于处理器、内存等的限制自己去搜吧。

 

Come from : http://hi.baidu.com/long886/blog/item/5e60d2ca1ce1844cf21fe7ac.html

 

sql server2005 无法修改表,超时时间已到 在操作完成之前超时时

在sql server2005 中,在修改表时,保存的时候显示:无法修改表,超时时间已到 在操作完成之前超时时间已过或服务器未响应
这是执行时间设置过短的原因,可以修改一下设置便能把执行时间加长,以便有足够的时间执行完修改动作。

在 SQL Server Management Studio 里,
通过菜单“工具-选项”打开选项对话框。
在左侧寻找“设计器-表设计器和数据库设计器”,
然后在右侧勾选“为表设计器更新重写连接字符串的超时值”,
在它下面的“事务超时时间”默认应该是 30 秒,我们应该把它改得稍微大一些。

建议,最好还是用语句形式进行修改。

SQL2005的18452的另一种解决办法

用sa登录SQL2005的SQL Server Authentication出现18452错误,在网上查找了一些相关资料,都没有解决问题。最后只能重新创建一个新用户进行SQL Server Authentication登录。
————————————————————————————————————————————网上查到的解决办法:
无法连接到服务器
服务器:消息18452,     级别16,状态1
[Microsoft][ODBC     SQL     Server     Driver][SQL     Server]用户‘sa’登陆失败。原因:未与信任SQL     Server连接相关联
该错误发生的原因是由于SQL     Server使用了”仅     Windows”的身份验证方式,因此用户无法使用SQL     Server的登录帐户(例如     sa )进行连接,解决方法如下

设置允许SQL     Server身份登录     (基本上这个很有用)
操作步骤:
1.在企业管理器中,展开”SQL     Server组”,鼠标右键点击SQL     Server服务器的名称
2.选择”属性”
3.再选择”安全性”选项卡
4.在”身份验证”下,选择”SQL     Server和     Windows”
5.确定,并重新启动SQL     Server服务。

________________________________________________________________________
创建新用户:
以Windoww Authentication方式登录进去:
1、对SQL Server点击鼠标右键—>Properties(属性)—>Security(安全)—>选SQL Server and Windows Authentication mode—->确定
2、输入以下语句
/*–示例说明
示例在数据库pubs中创建一个拥有表jobs的所有权限、拥有表titles的SELECT权限的角色r_test
随后创建了一个登录l_test,然后在数据库pubs中为登录l_test创建了用户账户u_test
同时将用户账户u_test添加到角色r_test中,使其通过权限继承获取了与角色r_test一样的权限
最后使用DENY语句拒绝了用户账户u_test对表titles的SELECT权限。
经过这样的处理,使用l_test登录SQL Server实例后,它只具有表jobs的所有权限。
–*/

USE pubs

–创建角色 r_test

EXEC sp_addrole ‘r_test’

–授予 r_test 对 jobs 表的所有权限

GRANT ALL ON jobs TO r_test

出现这句时不用去理–(The ALL permission is deprecated and maintained only for compatibility. It DOES NOT imply ALL permissions defined on the entity.
)
–授予角色 r_test 对 titles 表的 SELECT 权限

GRANT SELECT ON titles TO r_test

–添加登录 l_test,设置密码为pwd,默认数据库为pubs

EXEC sp_addlogin ‘l_test’,’pwd’,’pubs’

–为登录 l_test 在数据库 pubs 中添加安全账户 u_test

EXEC sp_grantdbaccess ‘l_test’,’u_test’

–添加 u_test 为角色 r_test 的成员

 

对新用户l_test进行设置:

1、在SQL Server的security文件夹下的—>Logins文件夹—>l_test点击鼠标右键选择Properties—>选择Server Roles里勾选publice和sysadmin—>选择User Mapping里勾选上面设的数据库和db_owner,public及上面设置的r_test角色—>status里选择Grant,Enabled。

2、关闭SQL。

3、在控制面板–管理工具–服务里重启SQL Server(SQLEXPRESS)服务。

4、重新使用用户名为l_test密码为pwd进行SQL Server Authentication
___________________________________________________________________

以下为删除所设置的新用户:
EXEC sp_addrolemember ‘r_test’,’u_test’

–拒绝安全账户 u_test 对 titles 表的 SELECT 权限

DENY SELECT ON titles TO u_test

/*–完成上述步骤后,用 l_test 登录,可以对jobs表进行所有操作,但无法对titles表查询,虽然角色 r_test 有titles表的select权限,但已经在安全账户中明确拒绝了对titles的select权限,所以l_test无titles表的select权限–*/

–从数据库 pubs 中删除安全账户

EXEC sp_revokedbaccess ‘u_test’

–删除登录 l_test

EXEC sp_droplogin ‘l_test’

–删除角色 r_test

EXEC sp_droprole ‘r_test’

 

 

http://blogold.chinaunix.net/u2/69626/showart_1977818.html