I've never seen a case where the same child that does the update/insert doesn't return the new data on a subsequent view reload.
Good, you're narrowing it down. If a different child handles the edit and the view, is it always wrong? You can simulate this when running in -X by doing the edit, then stopping and restarting the server, then doing the view.
I have tried varying the input and that has not changed the results. In the most recent test's I am ignoring the form data (hard-coding the data in the insert).
Okay, so you've eliminated more of the processing chain.
In regular mode (not -X), I just did 2 edits (inserts) confirmed that the rows are in the db using the mysql client, and the view page reloads are showing the same thing: some show the new inserts some don't.
Because I always see the data in the database with the mysql client, I figured it wasn't an issue with the view page per-se, more a problem with the insert (new data) not being seen by the child.
So the data always gets written to the database, but sometimes doesn't show up when you select it on the view page? I'd suggest focusing on the view page then, until you find the exact place in the code where it starts doing something unexpected. That may not be the source of the problem, but it may tell you what the problem is.
How should I be resetting the db (mysql)?
What I meant by that is clearing all of your test data between tries, so that you know you are doing exactly the same test each time and not just seeing left over problems from the last run.
- 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
