On Tue, 2004-05-18 at 19:15, Dave Boodman wrote: > I'm testing by submitting (in a browser) the page/form (the "edit" > page) that (at this point) just calls the code to do the insert (as > you can see I've specified the data to insert, ignoring what's in the > form). I do the same when I run in -X. To reproduce the error, I have > another browser open that retrieves the items for a given customer > (the "view" page). Immediately following the "edit" page submit. I > relaod the "view" page and corresponding to the # of hashes you see in > the logs I included, that's the # of items I see showing up.
Okay, so when you do this without -X, you have no way of knowing whether or not you hit the same child process twice or not. With -X on, try submitting the edit page several times in a row before pulling up the view page, or submitting the view page several times before pulling up the edit page, etc. That's the sort of thing that could be happening when you run without -X. If you vary the input to the edit page at all during your testing, experiment with that too. > The code that generates the "view" page and the hashes returned log > entries is: > > sub retrieve { > my $self = shift; > my $cid = shift; > my @out; > foreach my $obj (Lib::Systems->search(cid=>$cid)) { > # strip out the Class::DBI bits > my %e = map { $_ => $obj->$_ } Lib::Systems->columns; > push @out, \%e; > } > $self->model->log('debug', "retrieve($cid) returning ".scalar > @out." hashes" ); > return [EMAIL PROTECTED]; > > } # end retrieve You could try verifying that the SQL is getting the right thing by checking the database yourself before running the view page. If it looks the same, then you can eliminate the view page as a possible source of problems. > I tried your suggestion of replacing Lib::Systems with: > > from DBI.pm: > <SNIP> > use base 'Class::DBI'; > <SNIP> > sub dbh { > return DBI->connect(DB_DSN, DB_USERNAME, > DB_PASSWORD,{AutoCommit => 0}) > || die $DBI::errstr; > } # end dbh() > <SNIP> > > replaced code inside update(): > > my $db = Lib::Systems->dbh; > <SNIP> > eval { $db->do("insert into systems (cid,start_date,machine) values > ('col00179','2004-05-18','test')") }; > > and I get the same results. I don't know enough about your system to interpret that, but taking things out until the problem goes away is the right approach. Try hard-coding the input instead of actually reading the form data and see if that makes a difference. See what else you can take out. And make sure you are resetting your database between tries. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html