Hi,
I have two questions...
I'm writing a code something like this:
create query
run query using use()
while (mysqlpp::Row row = res.fetch_row()) {
try {
{{create and exec a stored procedure here}}
}
catch (...) {
}
}
I created two different connection object and use them for the loop and
for the inner execution.
Now, when the inner query (actually, executing a stored procedure to add
a record to two tables) fail and raise an exception, while trying to
unwind stack frame, program stuck at following read().. following is the
stack trace of the moment.
#0 0x900108c7 in read ()
#1 0x00431092 in vio_read_buff ()
#2 0x004323f8 in my_real_read ()
#3 0x004325db in my_net_read ()
#4 0x0042c0b9 in net_safe_read ()
#5 0x0042c1cf in cli_flush_use_result ()
#6 0x0042c248 in mysql_free_result ()
#7 0x00479c42 in mysqlpp::ResUse::purge ()
#8 0x0040e4c6 in mysqlpp::ResUse::~ResUse ()
#9 0x0000590c in CDBSupport_MySQL::DoEtherFrameScanByCondition
(this=0x1100a60, ef=0xbffff858, where=@0xbffff53c, orderby=@0xbffff538)
at db_support_mysql.cpp:276
#10 0x00024a69 in CDBSupport::EtherFrameScanByCondition (ef=0xbffff858,
where=@0xbffff53c, orderby=@0xbffff538) at db_support.h:118
#11 0x0000c723 in CSource_DB_EtherFrame::ScanByCondition
(this=0xbffff858, where=@0xbffff53c, order=@0xbffff538) at
source_db_etherframe.cpp:33
#12 0x0000c85c in CSource_DB_EtherFrame::ScanBySourceID
(this=0xbffff858, source=1) at source_db_etherframe.cpp:26
#13 0x000029e9 in MyEtherSessionScanner::Scan (this=0xbffff854,
file=@0xbffff85c) at ipv4index.cpp:80
#14 0x00002b15 in main (ac=1, av=0xbffff8ec) at ipv4index.cpp:112
It looks like trying to free ResUse object but no luck.
Now, questions:
1) Why this is happening?
2) Is there any way to exec a stored procedure, while reading result
using fetch_row() other than using two connections like this?
I'm currently using MySQL 5.0.24 on MacOS X, but by some reason, I built
binary by myself. (via ported NetBSD Package) Both client program and
server run on same box. I will try on NetBSD too, but I doubt OS is the
source of problem..
shigeya

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.