Version: 0.1 -pre1 (using KDE 3.4.0, Gentoo) Compiler: gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) OS: Linux (i686) release 2.6.9 is it one or two bug, I'm not sure but here is what happen. I am connected to a remote mysql database. doing some other stuff, the connection with the database seems to timeout something. I'm also behind a router so that could be it, or maybe not at all since the link is still ESTABLISH under netstat. anyway, I'm trying to create a new table, and kexi error out saying "No Database Selected" which looks strangely similar to the mysql error message when you mysql in and try to do some stuff without connecting to an actual database. mysql> select 1 from x; ERROR 1046: No Database Selected mysql> I think in this situation, kexi should check if the connection is still well establish and well working, if not, trying to reestablishing in the background and then try to do the user operation. if can't reestablish connection, then error out... but, this case should be on a network problem or something. here is the second bug, which can be entirely related, but also need a separate patch. I continue playing with my unconnected kexi instance, jump to an existing table, jump into insertion modes. (does not show any rows, maybe it could have shown cached one or something, I dont know, but I did not have any....) the empty line saying autoincrement... was not shown either to add a new one. I played with the buttons at the bottom (go last row, add new row) and kexi crashed. hope this help. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 634)] [KCrash handler] #5 0x40196fa5 in KexiTableView::keyPressEvent(QKeyEvent*) (this=0x8319470, e=0xbfffea40) at kexitableview.cpp:2387 #6 0x412a493d in QWidget::event(QEvent*) (this=0x8319470, e=0xbfffea40) at kernel/qwidget.cpp:4719 #7 0x411f15a9 in QApplication::internalNotify(QObject*, QEvent*) ( this=0xbfffef90, receiver=0x8319470, e=0xbfffea40) at kernel/qapplication.cpp:2635 #8 0x411f0944 in QApplication::notify(QObject*, QEvent*) (this=0xbfffef90, receiver=0x8319470, e=0xbfffea40) at kernel/qapplication.cpp:2392 #9 0x40cf734d in KApplication::notify(QObject*, QEvent*) (this=0xbfffef90, receiver=0x8319470, event=0xbfffea40) at kapplication.cpp:549 #10 0x41179bd6 in QApplication::sendSpontaneousEvent(QObject*, QEvent*) ( receiver=0x8319470, event=0xbfffea40) at qapplication.h:494 #11 0x41174045 in QETWidget::translateKeyEvent(_XEvent const*, bool) ( this=0x8319470, event=0xbfffee30, grab=false) at kernel/qapplication_x11.cpp:5488 #12 0x4116f539 in QApplication::x11ProcessEvent(_XEvent*) (this=0xbfffef90, event=0xbfffee30) at kernel/qapplication_x11.cpp:3479 #13 0x4118ca0d in QEventLoop::processEvents(unsigned) (this=0x810d2e0, flags=4) at kernel/qeventloop_x11.cpp:192 #14 0x41208979 in QEventLoop::enterLoop() (this=0x810d2e0) at kernel/qeventloop.cpp:198 #15 0x41208892 in QEventLoop::exec() (this=0x810d2e0) at kernel/qeventloop.cpp:145 #16 0x411f174b in QApplication::exec() (this=0xbfffef90) at kernel/qapplication.cpp:2758 #17 0x4001a15a in kdemain (argc=9, argv=0xbffff0e4) at main.cpp:199 #18 0x0804888f in main (argc=-1073748592, argv=0xbfffe590) at kexi.la.cpp:2
full error message (same error number as my small mysql isolated testcase) Creating table failed. Error while executing SQL statement. Message from server: No Database Selected SQL statement: CREATE TABLE table1 (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, efefe VARCHAR(200)) Server result number: 1046
another backtrace.... I reopen my mysql connection (new kexi instance) and wait until it times out. then create a new table and try save to save it. same error. exit kexi, ask for saving changes (the table) :) Sure I said. can't save, same errror message, kexi crashed out. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 24401)] [KCrash handler] #5 0x4001a481 in QString::length() const (this=0x0) at qstring.h:880 #6 0x403a3992 in KexiDB::Connection::isDatabaseUsed() (this=0x0) at connection.cpp:183 #7 0x403b7a94 in KexiDB::Connection::beginTransaction() (this=0x0) at connection.cpp:1564 #8 0x403dda07 in TransactionGuard (this=0xbfffe780, conn=@0x0) at transaction.cpp:133 #9 0x4022ccf2 in KexiProject::removeObject(KexiMainWindow*, KexiPart::Item&) ( this=0x82280c0, wnd=0x0, item=@0x815aa40) at kexiproject.cpp:427 #10 0x40063f93 in KexiMainWindowImpl::removeObject(KexiPart::Item*, bool) ( this=0x81592e8, item=0x815aa40, dontAsk=32) at keximainwindowimpl.cpp:2778 #11 0x400622a0 in KexiMainWindowImpl::closeDialog(KexiDialogBase*, bool) ( this=0x81592e8, dlg=0x82cc538, layoutTaskBar=true) at keximainwindowimpl.cpp:2313 #12 0x40061f0f in KexiMainWindowImpl::closeDialog(KexiDialogBase*) (this=0x0, dlg=0x0) at keximainwindowimpl.cpp:2268 #13 0x4005d163 in KexiMainWindowImpl::closeProject() (this=0x81592e8) at keximainwindowimpl.cpp:967 #14 0x40058742 in ~KexiMainWindowImpl (this=0x81592e8) at keximainwindowimpl.cpp:424 #15 0x4125e9d6 in QObject::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kernel/qobject.cpp:750 #16 0x412a466f in QWidget::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kernel/qwidget.cpp:4655 #17 0x41386222 in QMainWindow::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at widgets/qmainwindow.cpp:1686 #18 0x402a7f39 in KMdiMainFrm::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kmdimainfrm.cpp:1166 #19 0x411f15a9 in QApplication::internalNotify(QObject*, QEvent*) ( this=0xbfffefb0, receiver=0x81592e8, e=0x82ffb20) at kernel/qapplication.cpp:2635 #20 0x411f121b in QApplication::notify(QObject*, QEvent*) (this=0xbfffefb0, receiver=0x81592e8, e=0x82ffb20) at kernel/qapplication.cpp:2523 #21 0x40cf734d in KApplication::notify(QObject*, QEvent*) (this=0xbfffefb0, receiver=0x81592e8, event=0x82ffb20) at kapplication.cpp:549 #22 0x401ae9ed in QApplication::sendEvent(QObject*, QEvent*) (receiver=0x0, event=0x5c) at qapplication.h:491 #23 0x411f25f2 in QApplication::sendPostedEvents(QObject*, int) (receiver=0x0, event_type=52) at kernel/qapplication.cpp:3261 #24 0x41208a40 in QEventLoop::enterLoop() (this=0x810d270) at kernel/qeventloop.cpp:213 #25 0x41208892 in QEventLoop::exec() (this=0x810d270) at kernel/qeventloop.cpp:145 #26 0x411f174b in QApplication::exec() (this=0xbfffefb0) at kernel/qapplication.cpp:2758 #27 0x4001a15a in kdemain (argc=8, argv=0xbffff104) at main.cpp:199 #28 0x0804888f in main (argc=0, argv=0x0) at kexi.la.cpp:2
In your backtrace: #12 0x40061f0f in KexiMainWindowImpl::closeDialog(KexiDialogBase*) (this=0x0, dlg=0x0) at keximainwindowimpl.cpp:2268 This=0x0 is weird here. Could not reproduce... Regarding to your "kexi should check if the connection is still well establish and well working" wish: that's right and requires nontrivial architecture changes, so I wouldn't do this for 1.0, while stabilization process started.