PDA

View Full Version : Simple removeRows isn't working...



scott_hollen
12th May 2011, 17:42
I feel like I keep stumbling on hard things to solve with simple code. I have 2 models, one a child of another, and the user of my app can delete a parent record, and subsequent child records. The problem is -- my model->removeRow command comes back as TRUE but no rows are removed from the model or the database even though I've performed a submitAll(). I count the rows in the child model before and it comes back with a count of 2, and after the removeRows() it's still equal to 2.

The models are defined such that selecting the parent filters the child model. And adding rows works fine.

Anyone have a thought? Thanks! (oh, and the qDebug() commands are just temporary for better error handling after I get it working)


void MainWindow::on_DeleleRegionPB_clicked()
{
int region_index;

region_index = regionmapper->currentIndex ();
qDebug() << flowlinemodel->rowCount ();

if (!flowlinemodel->removeRows (0, flowlinemodel->rowCount ()))
qDebug() << "Not able to delete flowline rows";
else
qDebug() << "woo-Who!";


// for (int i = 0; i < flowlinemodel->rowCount (); i++)
// {
// if (!flowlinemodel->removeRow (i))
// qDebug() << "issues";
// }

flowlinemodel->submitAll ();
qDebug() << flowlinemodel->rowCount ();

if (!regionmodel->removeRow (region_index))
qDebug() << "Not able to remove Region row";

if (region_index > 0)
regionmapper->setCurrentIndex (region_index - 1);
else
regionmapper->setCurrentIndex (region_index);

refresh_RegionView ();
set_Next_Previous_buttons();
}



scott

wysota
13th May 2011, 00:19
Please provide more info on the models.

ChrisW67
13th May 2011, 01:19
Are there integrity constraints in the underlying database that might be violated by removing these rows?

scott_hollen
25th May 2011, 01:22
Thanks for reply -- I've completely redesigned this since then (thanks to my father-in-law's brilliant communications skills of saying one thing and meaning another), so this thread should be removed...

Turns out, no, there weren't any constraints...I had had them on, but took them off thinking they were the problem...As part of my learning curve with cute, I've come to realize that using the model/view classes can sometimes cause unexpected results so I've gone straight to SQL a few times so that I know exactly how the code is behaving...Coming from a day job of Oracle I feel a lot more comfortable depending on the order of delete/insert/update at that level since I have no easy way of peeking at how the models (and in some cases the mapping) behave...

thanks for the reply, though!


scott