MySQL Connector++ 使用getString获取表字段数据出错

Linux下一个使用MySQL Connector++ 1.1.0 连接MySQL数据库的程序,在连接数据库获取数据时程序崩溃,
确定数据库中存在记录值,查看Core Dump文件,发现崩溃点发生在调用 MySQL 库的 getString 方法时的那一行,

通过google搜索,发现好一些getString出错的问题,但是多数是Windows下VS编译环境不同造成的,终于发现下面一篇中有和我的问题类似

http://stackoverflow.com/questions/4822958/mysql-c-connector-getstring-doesnt-work-correctly-while-getint-works-perfe

I had a similar problem the program would give a memory exception. Here is what I did to fix it:
std::string version = result->getString( COLUMN_NAME ).c_str();

This didn't work:
sql::SQLString sString  = result->getString( COLUMN_NAME ); <<

我的不正常代码是

std::string value = result->getString( field);

按照上面的方法将代码修改为

std::string value = result->getString( field).c_str();

暂时获取同样的数据没有出错,希望后面也不要出错。
MySQL Connector++ 从版本1.1.4开始编译依赖于BOOST库

Popularity: 2% [?]

Random Posts

    启动MySQL报Fatal error: Can’t open and lock privilege tables: Table ‘mysql.host’ doesn’t exist

    今天在服务器上另开一个MySQL,新建一个配置文件修改了端口,存放目录后,服务起不来,查看错误日志发现错误行

    Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist 

    检查数据目录,发现mysql目录没有被创建,手动执行脚本

    mysql_install_db --usrer=mysql --datadir=/var/lib/mysql/newdata

    再手工设置一下目录权限

    chown mysql.mysql /var/lib/mysql/newdata -R 

    重新开启MySQL服务,运行正常

    Popularity: 3% [?]

    Random Posts

      给MySQL的show table status结果做过滤

      MySQL中可以使用 show table status 查看表的状态,但是不能像select 语句选出结果那样做结果过滤。

      有没有办法像select语句那样过滤呢,答案是有的,就是从information_schema库的tables表中查询。

      如下是模仿show table status 的SQL:

      SELECT table_name,Engine,Version,Row_format,table_rows,Avg_row_length,
        Data_length,Max_data_length,Index_length,Data_free,Auto_increment,
        Create_time,Update_time,Check_time,table_collation,Checksum,
        Create_options,table_comment
      FROM information_schema.tables
      WHERE Table_Schema='MyDataBaseName';
      

      注意替换MyDataBaseName的名称为自己的库名称,这样就可以方便在Where部分添加各种条件过滤了。

      Popularity: 3% [?]

      Random Posts

        mysql运行出现Can’t open and lock privilege tables: Incorrect file format ‘host’

        一个安装lenny-debian系统的小设备,手快升级mysql后再启动mysql出现

        120101 15:14:21  InnoDB: Started; log sequence number 0 73553
        120101 15:14:21 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
        120101 15:14:21 [Note] Starting crash recovery...
        120101 15:14:21 [Note] Crash recovery finished.
        120101 15:14:21 [ERROR] Fatal error: Can't open and lock privilege tables: Incorrect file format 'host'
        
        总是启动不了,google了一下,试验后发现使用下方法可以正常修复
        step 1.使用 mysqld --skip-grant 命令启动mysql
        step 2.使用 mysqldump 将库数据导出
        step 3.使用 mysqladmin shutdown 停止mysqld 服务
        step 4.在shell 下进入mysql数据目录,删除下面的 mysql 库
        step 5.运行 mysql_install_db 重新创建默认的 mysql 库
        step 6.运行mysqld服务,检查导入库数据,重新创建库用户、密码以及设置权限
        step 7.执行cat /etc/mysql/debian.cnf 查看 debian-sys-maint帐号密码,运行mysql执行如下命令添加帐号
        mysql> GRANT ALL PRIVILEGES ON *.*  TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '前面看到的密码' WITH GRANT OPTION;
        mysql> FLUSH PRIVILEGES;
        如果已有debian-sys-maint帐号,可以使用如下命令修改密码为前面看到的
        mysql>SET PASSWORD FOR 'debian-sys-maint'@'localhost' = PASSWORD('前面看到的密码');
        mysql> FLUSH PRIVILEGES;
        
        (如没有重要数据,可以忽略步骤1,2,3)

        Popularity: 3% [?]

        Random Posts

          MYSQL 遭遇 The total number of locks exceeds the lock table size

          今天进行MySql 一个表数据的清理,经过漫长等待后出现 The total number of locks exceeds the lock table size 提示。以为是table_cache的值设置小了,于是将其值修改变大, 重启 MySQL 服务,再次执行表的清理操作,经过漫长时间等待后,同样的问题再次出现。网上google搜索相关问题,发现这么一段:

          If you’re working with a large InnoDB table and you’re updating, inserting, or deleting a large volume of rows, you may stumble upon this error:

          ERROR 1206 (HY000): The total number of locks exceeds the lock table size

          InnoDB stores its lock tables in the main buffer pool. This means that the number of locks you can have at the same time is limited by the innodb_buffer_pool_size variable that was set when MySQL was started. By default, MySQL leaves this at 8MB, which is pretty useless if you’re doing anything with InnoDB on your server.

          原来是InnoDB表执行大批量数据的更新,插入,删除操作时会出现这个问题,需要调整InnoDB全局的innodb_buffer_pool_size的值来解决这个问题。
          于是对照者检查了一下我的表类型,发现果然是InnoDB类型的,于是按照提示,修改 innodb_buffer_pool_size 的值,再一次重启mysql服务器,执行表清理操作,经过漫长时间等待后,终于成功执行完毕。

          有无办法不用重启MySQL服务器做清理呢?
          按照那篇文章介绍,可以将清理的操作分为几段,每次清理一部分(比如清理5-10%的数据),使每次的清理不会超出lock table size 的限制,这样就可以在不重新启动MySQL的情况下完成数据清理。

          Popularity: 3% [?]

          Related

          使用MySQL Connector C++的PreparedStatement更新数据碰到类型异常

          使用MySQL Connector C++ 的preparedStatement,在更新数据时,碰到异常

          1.  pstmt = con->prepareStatement("INSERT INTO logs(day, time, uid, vid, cid, cv, did, res) VALUES (?,?, ?,?, ?,?, ?,?)");
          2.  pstmt->setInt(1, day);
          3.  pstmt->setInt(2, time);
          4.             //…..
          5.         pstmt->setInt(8, res);
          6.  
          7.  pstmt->executeUpdate();

          执行executeUpdate时碰到异常: Using unsupported buffer type: 0 (parameter: 1)

          不知道怎么回事,使用google搜索了一会,没有找到解决方法。
          没有办法,将相关代码替换使用Statement的execute方法处理,执行ok

          Popularity: 3% [?]

          Related

          源码安装Mysql提示No curses/termcap library found

          使用源码方式安装Mysql5.0,提示No curses/termcap library found
          google了一下,
          下载一个ncurses-5.6.tar.gz安装,

          1. wget http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.6.tar.gz
          2. tar zxvf ncurses-5.6.tar.gz
          3. cd ncurses-5.6
          4. ./configure –prefix=/usr –with-shared –without-debug
          5. make
          6. make install clean

          网上还有一篇说在./configure 时添加 –with-named-curses-libs=/usr/lib/libncurses.so.5 解决,但是添加后虽然./configure通过,但是在make时失败
          在这儿记录一下

          Popularity: 3% [?]

          Related

          在Shell中执行Mysql语句

          使用shell脚本做日志分析,为了将分析后的结果直接存储到mysql数据库中需要在shell脚本中执行mysql的语句。
          方法一 将每一步需要执行的语句保存到 tmp.sql 中,最后在使用

          1.   mysql -u uname -p pwd < tmp.sql

          方式执行

          方法二 使用参数传递执行
          mysql -u$user -p$pass -D $db -e “select afield from atable;”
          : 对test.dat中的每一行拼装成sql做执行

          1. cat test.dat |awk '{print "insert into table(a, b) values(\047" $1 "\047, \047" $2 "\047)" }'|while read line
          2. do
          3.   mysql -u$user -p$pass -D $db -e $line
          4. done

          其中 awk print命令中的 \047 代表单引号

          Popularity: 2% [?]

          Related

          在RHEL5.3上安装基于postfix的extmail邮件系统

          extmail官方网站上的安装指南是针对4.x系统的,网上找了一个5.x的安装。
          参考在centos/redhat 5.x 上安装邮件系统postfix+extmail+courier-imap

          安装步骤.

          1.系统准备

          使用默认方式安装系统后,从RHEL安装盘上拷贝一些下面安装步骤需要的rpm包先安装上。

          1. rpm -ivh postgresql-devel-8.1.11-1.el5_1.1.i386.rpm
          2. rpm -ivh expect-5.43.0-5.1.i386.rpm
          3. rpm -ivh libtool-ltdl-devel-1.5.22-6.1.i386.rpm
          4.  
          5. rpm -ivh mysql-devel-5.0.45-7.el5.i386.rpm
          6. rpm -ivh openldap-servers-2.3.43-3.el5.i386.rpm
          7. rpm -ivh openldap-servers-sql-2.3.43-3.el5.i386.rpm
          8.  
          9. rpm -ivh pcre-6.6-2.el5_1.7.i386.rpm
          10. rpm -ivh pcre-devel-6.6-2.el5_1.7.i386.rpm

          再从 www.extmail.org 网站上下载最新的 extmail 相关包

          extmail-1.1.0.tar.gz
          extman-1.0.0.tar.gz
          slockd-0.99.tar.gz
          

          2.导入extman后台数据库数据

          1. tar -xzvf extman-1.0.0.tar.gz
          2. cd extman-1.0.0/docs
          3. mysql -u root -p
          4. mysql> source extmail.sql
          5. mysql> source init.sql
          6. mysql> exit

          Read more

          Popularity: 9% [?]

          Related

          SQL SERVER数据库碰到823错误不能启动的解决方法

          由于机器意外断电重启,发现SQL Server 服务不能启动。查看系统的事件日志,发现有错误提示:
          ———————————-
          服务器: 消息 823,级别 24,状态 5
          ———————————-
          对数据库启动错误信息进行细节排查,发现其中有ErrorDB出错,不能附加这个数据库,从而整个SQL Server 服务不能启动。

          修复方法
          1. 将已破坏的ErrorDB数据库文件更名,如ErrorDB_Data.Mdf ==>ErrorDB_Data1.Mdf, ErrorDB_Log.Ldf==>ErrorDB_Log1.Ldf

          2. 再次启动SQL Server服务,发现可以正常启动服务,但是会看到ErrorDB显示为置疑状态,将其分离,重新建立一个同名的ErrorDB数据库。

          3. 选中新建的数据库,将其脱机, 然后到数据库数据目录下将新数据库更名(ErrorDB_Data.Mdf ==> ErrorDB_Data2.Mdf), 将待修复老数据库更名为原先名称ErrorDB_Data1.Mdf ==> ErrorDB_Data.Mdf

          4. 在SQL查询分析器中, 执行如下命令:
          use master
          sp_configure ‘allow’, 1
          reconfigure with override
          update sysdatabases set status = 32768 where name = ‘ErrorDB’

          5. 将LDF文件改名,然后将ErrorDB联机,再在查询分析器中执行
          DBCC REBUILD_LOG (‘ErrorDB’, ‘E:\Data\ErrorDB_Log.LDF’ )

          6. 恢复数据库紧急模式
          update sysdatabases set status = 0 where name = ‘ErrorDB’

          7. 在查询分析器中执行
          restore database ErrorDB with recovery
          sp_configure ‘allow’, 0
          reconfigure with override

          8. 检查数据库看看还有没有错误,
          DBCC CHECKDB (‘ErrorDB’)

          ————-
          如以上还是不行,可以尝试使用
          DBCC CHECKDB(‘ErrorDB’, Repair_Allow_Loss_Data)
          命令修复数据库,不过这样会丢失一些数据,但是话说回来,貌似不这样那些坏掉的数据也回不来的。
          ————-
          在做以上处理时,要注意关闭使用ErrorDB的程序。要不然某些步骤会提示不能获得数据库的排他性操作权限,不能对命令进行执行处理。

          Popularity: 2% [?]

          Related

          Next Page →