日志分类:数据库|SQLServer

Access与SQL Server互相转换的不同点

2008-05-31,星期六 | 分类:数据库|SQLServer | 153 views

有的时候我们会遇到access(小型网站之最爱)转换到SQL Server,或者SQL Server转换成access(小型网站之最爱)数据库的需要,如果SQL Server不使用存储过程的话,转换器来总体来说没什么大的变化,如果你使用的是ASP编写的代码,那么连代码也不需要怎么修改,但是还是有些不同之处需要大家注意的,这些都是icech长期以来积累的经验,供大家参考:
1、自动编号的问题
access(小型网站之最爱)转换成SQL Server,所有的自动编号都会消失。需要在access(小型网站之最爱)中修改为自动增加字段。
SQL Server转换成access(小型网站之最爱),那么自动编号也会消失,那么在转换过程中注意将SQL语句修改成IDENTITY (1, 1)就可以了,网上很多相关的文章。

全文阅读 »

解决SQL Server转ACCESS后自动编号问题

2008-05-31,星期六 | 分类:数据库|SQLServer | 205 views

1.打开sql server(WINDOWS平台上强大的数据库平台) enterprise mananger “企业管理器”
在你要导出的SQL数据库上鼠标右键菜单:所有任务-》导出数据

全文阅读 »

如何修复损坏的MySQL数据表

2008-05-31,星期六 | 分类:数据库|SQLServer | 145 views

于断电或非正常关机而导致MySQL(和PHP搭配之最佳组合)数据库出现错误是非常常见的问题。有两种方法,一种方法使用MySQL(和PHP搭配之最佳组合)的check table和repair table 的sql语句,另一种方法是使用MySQL(和PHP搭配之最佳组合)提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆MySQL(和PHP搭配之最佳组合) 终端:
MySQL(和PHP搭配之最佳组合) -uxxxxx -p dbname
> check table tabTest;
如果出现的结果说Status是OK,则不用修复,如果有Error,可以用:
> repair table tabTest;
进行修复,修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。

全文阅读 »

如何缩小MSSQL数据库的大小(日志)

2008-05-31,星期六 | 分类:数据库|SQLServer | 137 views

mssql(WINDOWS平台上强大的数据库平台)数据库的大小包含数据(Data)和事务日志(TransactionLog)两个部分。
数据部分存储的是用户数据库中的数据,包含用户的数据表、视图、存储过程等等内容。
数据部分一般存储与数据库文件组中的.mdb文件中。一般来说,在正常使用的情况下,这
个部分的大小不会经常性地发生很大的变化,除非是用于存储论坛之类快速变化的数据内
容。一般而言,这个部分很少会需要缩小。

全文阅读 »

Microsoft SQL Server 2008 CTP下载

2008-04-29,星期二 | 分类:数据库|SQLServer | 209 views

Microsoft SQL Server 2008 是下一版本的 Microsoft SQL Server,为关键任务应用程序提供更加安全、可靠、可管理和可缩放的全面数据平台,同时让开发人员创建可以在任何设备上存储和使用任何类型数据的新应用程序,让所有用户深入了解相关信息,做出明智的决定。

  此 CTP 将于 180 天后自动过期。
  下载:Microsoft SQL Server 2008 CTP

visualbasic得到SQL存储过程返回值

2008-04-23,星期三 | 分类:数据库|SQLServer | 标签: | 226 views

‘存储过程:

ALTER procedure aa_pname
@fdate varchar(10),
@fyear integer out,
@fmonth integer out
as

begin
–内容
end

全文阅读 »

关于修改SQL SERVER排序规则

2008-04-15,星期二 | 分类:数据库|SQLServer | 标签: | 416 views

1.修改排序规则
alter database 库名 collate SQL_Latin1_General_CP1_CI_AS –collate后面是排序规则名

2.如何将collation name=SQL_Latin1_General_CP1_CI_AS的数据库完整复制到另一个collation name=Chinese_PRC__CI_AS的空数据库中?

你可以把collation name=SQL_Latin1_General_CP1_CI_AS数据库的结构生成脚本
sql200企业管理器
–右键要导出的数据库
–所有任务
–生成SQL脚本
–常规里选择生成全部对象脚本
–设置格式里,将”包含扩展属性”与”仅为与7.0兼容而编写脚本”选上
–选项中,将”表脚本选项”中的内容全部选择上
–其他所有的选项保持默认值–然后确定,将其保存成一个.sql文件

全文阅读 »

SQL Server 2005 修改表结构超时的解决办法

2008-04-09,星期三 | 分类:数据库|SQLServer | 标签: | 470 views

当要修改的表中数据很多时总是超时,只要按照下面设置一下就可以了
工具–选项–设置器 将事务超时时间设置大一些(默认为30秒)

迁移SQL数据库五招

2008-03-12,星期三 | 分类:数据库|SQLServer | 标签: | 132 views

我是一家图书公司的数据库管理员,要维护多台服务器中的数据库,经常把某台服务器中的某个数据库移动到另外一台服务器,有时候也从其它分部拖数据到总公司,因此对数据移动有些心得体会,在这里拿出来同大家交流一下,如有不足之处请大家多多指教。

DTS设计器导入导出

DTS的设计器功能强大,支持多任务,也是可视化界面,容易操作,但知道的人一般不多,如果只是进行SQL Server数据库中部分表的移动,用这种方法最好,当然,也可以进行全部表的移动。在SQL Server Enterprise Manager中,展开服务器左边的+,选择数据库,右击,选择All tasks/Import Data…(或All tasks/Export Data…),进入向导模式,按提示一步一步走就行了,里面分得很细,可以灵活的在不同数据源之间复制数据,很方便的。而且可以另存成DTS包,如果以后还有相同的复制任务,直接运行DTS包就行,省时省力。也可以直接打开DTS设计器,方法是展开服务器名称下面的Data Transformation Services,选Local Packages,在右边的窗口中右击,选New Package,就打开了DTS设计器。

值得注意的是:如果源数据库要拷贝的表有外键,注意移动的顺序,有时要分批移动,否则外键主键,索引可能丢失,移动的时候选项旁边的提示说的很明白,或者一次性的复制到目标数据库中,再重新建立外键,主键,索引。

利用备份和恢复

先对源数据库进行完全备份,备份到一个设备(device)上,然后把备份文件复制到目的服务器上(恢复的速度快),进行数据库的恢复操作,在恢复的数据库名中填上源数据库的名字(名字必须相同),选择强制型恢复(可以覆盖以前数据库的选项),再选择从设备中进行恢复,浏览时选中备份的文件就行了。这种方法可以完全恢复数据库,包括外键,主键,索引。

直接拷贝数据文件

把数据库的数据文件(*.mdf)和日志文件(*.ldf)都拷贝到目的服务器,在SQL Server Query Analyzer中用语句进行恢复:
EXEC sp_attach_db @dbname = ‘test’,
@filename1 = ‘d:mssql7datatest_data.mdf’,
@filename2 = ‘d:mssql7datatest_log.ldf’
这样就把test数据库附加到SQL Server中,可以照常使用。如果不想用原来的日志文件,可以用如下的命令:
EXEC sp_detach_db @dbname = ‘test’
EXEC sp_attach_single_file_db @dbname = ‘test’,
@physname = ‘d:mssql7datatest_data.mdf’

这个语句的作用是仅仅加载数据文件,日志文件可以由SQL Server数据库自动添加,但是原来的日志文件中记录的数据就丢失了。

在应用程序中定制

可以在应用程序(PB、VB)中执行自己编写的程序,也可以在Query Analyzer中执行,这种方法比较灵活,其实是利用一个平台连接到数据库,在平台中用的主要是SQL语句,这种方法对数据库的影响小,但是如果用到远程链接服务器,要求网络之间的传输性能好,一般有两种语句:

1> select … into new_tablename where …
2> insert (into) old_tablename select … from … where …

区别是前者把数据插入一个新表(先建立表,再插入数据),后者是把数据插入已经存在的一个表中,我个人喜欢后者,因为在编程的结构上,应用的范围上,第二条语句强于前者。

SQL Server的复制功能

SQL Server提供了强大的数据复制功能,也是最不易掌握的,具体应用请参考相关资料,值得注意的是要想成功进行数据的复制工作,有些条件是必不可少的:

1)SQL Server Agent必须启动,MSDTC必须启动。
2)所有要复制的表必须有主键。
3)如果表中有text或image数据类型,必须使用with log选项,不能使用with no_log选项。
另外max text repl size选项控制可以复制的文本和图像数据的最大规模,超过这个限制的操作将失败。
4)在要进行复制的计算机上,应该至少是隐含共享,即共享名是a1、b1…。
5)为SQL Server代理使用的Windows Server账号不能是一个本地的系统账号,因为本地的系统账号不允许网络存取。

如何在SQL Server数据库中加密数据

2008-02-08,星期五 | 分类:数据库|SQLServer | 标签: | 136 views

为了防止某些别有用心的人从外部访问数据库,盗取数据库中的用户姓名、密码、信用卡号等其他重要信息,在我们创建数据库驱动的解决方案时,我们首先需要考虑的的第一条设计决策就是如何加密存储数据,以此来保证它的安全,免受被他人窥测。

SQL Server中有哪一种支持可以用于加密对象和数据?从一开始就讨论一下SQL Server欠缺什么是明智的,或者是对于SQL Server中的加密部分你不应该做什么。

首先,SQL Server有两个内置的密码函数——即,pwdencrypt() 和 pwdcompare()。同时,还有两个SQL Server用来管理密码哈希的没有正式记录的函数:pwdencrypt() 将密码哈希过后进行存储;pwdcompare()将提供的字符串与哈希后的字符串进行比较。不幸的是,这个哈希函数不是非常安全,它可以通过字典攻击算法被破解(类似命令行应用程序!)。

这些函数随着SQL Server的版本发展而不断进行修改,这也是另一个没有使用它们的原因。早期版本的SQL Server对密码进行的哈希,在后来的版本中无法解密,所以如果你依赖一个版本中的函数,那么当升级的时候,所有你的加密数据就都没有用了,除非你可以首先对其解密——这也就违背了加密的最初的目的。

第二,你可能会尝试去创建一个针对你的数据库的自制的加密解决方案,但是有以下三个理由说明你不要这样做:

除非你是加密专家,否则胡乱编写的加密系统只会提供非常低级的价值不高的保护。新鲜的是,单向密码哈希或者 “ROTx “形式的加密几乎不需要费事就可以被轻松打败。

如果由于你自己的能力的缺乏而导致加密被破解,那么你的数据就完蛋了。你需要将所有的东西进行没有加密的备份,是吗?(即使你加密了,那里有没有安全漏洞?)

当市面上提供有专业级别的,具有工业强度的加密解决方案的时候,你就不值得花费时间去自己做。把你的时间用于构建一个好的,坚固的数据库,而不是再重新发明一次车轮。

那么,什么才是好的加密数据的方式呢?

对于新手,微软提供了一个自己生成的加密解决方案,CryptoAPI 。对于轻量级的加密,军用级别的安全就不在考虑范围之内,它具有相对容易实现的优势:管理员可以安装一个名为CAPICOM 的ActiveX 控制,它可以在T-SQL存储过程中提供CryptoAPI 功能。CAPICOM 支持各种类型的双向加密和单向哈希算法,所以管理员可以挑选最适合应用程序的问题的部分。

如果你对使用微软的解决方案不感兴趣,还有一些很好的第三方的方案可以使用。一家名为ActiveCrypt 的软件有限责任公司制造了XP_CRYPT ,它是SQL Server的插件,可以在视图、程序和触发器中通过扩展存储过程和用户自定义函数(在SQL Server 2000中)来完成加密。你可以下载一个支持无线的MD5,DES ,以及SHA1哈希的免费版本的应用程序;其他的加密模型就是在比特深度上进行的。(完全版本是无限的。)在你自己的代码中,你可以使用XP_CRYPT,与ActiveX 控制一样(在受限的免费版本中)。对于ASP程序员来说,一个名为AspEncrypt 的组件提供了一种将高级加密整合到你的代码中的简单方式。

对数据库文件自身进行加密或者提供传输层上的安全保护怎么样?对于前者,大家可以在Windows系统中持续使用加密文件系统。然而,你必须保存加密密钥的备份,在出现问题的时候,这个数据有可能会丢失。对于后者,有IPSec和SQL Server自己的SSL加密,都是SQL Server和Windows自带的大家的主要精力应该放在避免以明文存储敏感数据,因为从数据库中抽取没有加密的数据同样是最容易受到攻击的薄弱环节。

Pages: Prev 1 2 3 4 5 Next