应急密码、验证码等状态恢
FAQ系统开放
今天在修改数据库备份和导出部分时，遇到了怪事一桩。确认程序无误的情况下，导入怎么也不成功，MySQL报错为“Column count doesn't match”。查了半天也不知道原因，只好让程序一行行地检查备份数据。结果发现，问题出在某一篇很长的日志上。这篇日志的数据被php的gzfile()函数断为两行，难怪SQL语句会出错。
为了确认这是我的rpwt还是php的问题，到php.net上一看，果然有人反应了类似的问题：
好吧，承认被这个东西打败了。这个问题看来不只是4.4.1的问题，我在本机测试时php版本为5.0，也没有解决这个问题。看来现在暂时的解决方法是，大家在备份的时候不要选‘gz’格式，直接备份为bak文件。或者备份成gz文件，在导入之前手动解压成bak文件上传。
提示您的是备份和导入部分已经修改过，尽可能减少了发生错误的概率。请您到这个帖子下载新的程序：
http://www.bmforum.com/bmb/topic.php?filename=110752
为了确认这是我的rpwt还是php的问题，到php.net上一看，果然有人反应了类似的问题：
引用自 http://cn.php.net/manual/en/function.gzfile.php
In PHP4.4.1 I noticed that gzfile only reads up to 8190 bytes per line. I had a 20K SQL query that was cut into 3 parts - and wondered why the SQL server complained.
Reading an uncompressed file with the file() command works as expected.
Reading an uncompressed file with the file() command works as expected.
好吧，承认被这个东西打败了。这个问题看来不只是4.4.1的问题，我在本机测试时php版本为5.0，也没有解决这个问题。看来现在暂时的解决方法是，大家在备份的时候不要选‘gz’格式，直接备份为bak文件。或者备份成gz文件，在导入之前手动解压成bak文件上传。
提示您的是备份和导入部分已经修改过，尽可能减少了发生错误的概率。请您到这个帖子下载新的程序：
http://www.bmforum.com/bmb/topic.php?filename=110752
。。
等了好久了
http://www.couke.com/weblog/read.php/33.htm