Upgrading to 1.0.3

Get help from other users here.

Moderators: Developer, Contributor

Post Reply
atomoid
Posts: 108
Joined: 18 Aug 2005, 00:46
Location: santa cruz, ca

Upgrading to 1.0.3

Post by atomoid »

Okay, never mind this first post, i think it was due to a merging issue (i was missing the "fixed_in_version" at the end of the 'insert' section), but after fixing that i still get the problems noted further below...
--------------------------

After upgrading to 1.0.3 (from 1.0.1) Whenever reporting a new bug i would get:

Code: Select all

APPLICATION ERROR #401
Database query failed. Error received from database was #1136: Column count doesn't match value count at row 1 for the query: 

INSERT INTO mantis_bug_table ( project_id, reporter_id, handler_id, duplicate_id, priority, severity, reproducibility, status, resolution, projection, category, date_submitted, last_updated, eta, bug_text_id, os, os_build, platform, version, build, profile_id, summary, view_state, sponsorship_total, sticky )

VALUES ( '8', '78', '87', '0', '30', '60', '10', '10', '10', 10, 'Application', '2006-05-12 06:37:05','2006-05-12 06:37:05', 10, '3180', '', '', '', '1.0', '0.9.50', '0', 'blah blah blah', '10', '0', '0', '' )
After some digging around, it turns out that this is caused by an extra blank column in the 'values' section in mantis/core/bug_api.php on the last line here (line 408 after 'sticky') that is not matched by anything in the 'insert' section:

Code: Select all

	$query = "INSERT INTO $t_bug_table
				    ( project_id,
				      reporter_id, handler_id,
				      duplicate_id, priority,
				      severity, reproducibility,
				      status, resolution,
				      projection, category,
				      date_submitted, last_updated,
				      eta, bug_text_id,
				      os, os_build,
				      platform, version,
				      build,
				      profile_id, summary, view_state, sponsorship_total, sticky )
				  VALUES
				    ( '$c_project_id',
				      '$c_reporter_id', '$c_handler_id',
				      '0', '$c_priority',
				      '$c_severity', '$c_reproducibility',
				      '$t_status', '$t_resolution',
				      10, '$c_category',
				      " . db_now() . "," . db_now() . ",
				      10, '$t_text_id',
				      '$c_os', '$c_os_build',
				      '$c_platform', '$c_version',
				      '$c_build',
				      '$c_profile_id', '$c_summary', '$c_view_state', '$c_sponsorship_total', '$c_sticky', '' )";
This was introduced in 1.0.2 for some reason, but im not sure what it is for since i dont have access to read any closed bugs in the bugs.mantisbt.org database.

So by removing that final comma and qoutes at the end which is reponsible for the mismatch, that fixed it and everything now seems okay, but since im not proficient enough at PHP to know completely whats going on, I fear of course that if it is neccessary for some reason, it might manifest in some problem elsewhere if it were my changes that set it up to be broken, or if i was supposed to use the admin tools to "upgrade" the db for 1.0.3 to make it ready for that extra column, as I didnt see any requirement to do so in the release note for 1.0.3. I didnt want to risk doing that unless necessary.

What was that blank column for anyway?
and am i supposed to use the admin tool to upgrade the database?

Thanks,
-Eric
Last edited by atomoid on 12 May 2006, 23:14, edited 2 times in total.
atomoid
Posts: 108
Joined: 18 Aug 2005, 00:46
Location: santa cruz, ca

Post by atomoid »

After doing some more testing, i find that if i Delete a Bug Note, and let the timer expire to reload the next page i get:

Code: Select all

APPLICATION ERROR #203
A number was expected for id.
However, if i instead click on the link before the timer can expire:
  • Operation successful.
    [ Click here to proceed ]
- then the error doesnt occur and everything seems just fine (but there shouldn't be any difference as the timer essentially just effects this same command, right?)
...or might this be related to the situation reported above?
...or something completely unrelated...

after fixing the above problem by putting the bug_api.php code back in (the stuff after 'sticky', the <fixed_in_version> and the <, ''>:
then i now get a second error after the first one described above:

Code: Select all

APPLICATION ERROR #1100
Issue 0 not found.
Last edited by atomoid on 12 May 2006, 23:15, edited 2 times in total.
atomoid
Posts: 108
Joined: 18 Aug 2005, 00:46
Location: santa cruz, ca

Post by atomoid »

mail isnt getting sent anymore for any bug status changes, etc. however it works fine for password reset...

retreated back to 1.0.1 and everything includng mail works again.
Post Reply