I was not able to reproduce your problem with a fresh install of the latest stable version of MantisBT (1.2.15 at the moment) and the provided instructions.

I recommend that you upgrade to 1.2.15; if the problem persists after that, feel free to reopen the issue, and provide the following additional information:

• Exact version of MantisBT, PHP, Database, Web server and Operating System
• Relevant customizations (e.g. changes in config_inc.php, etc)
• Installed plugins or custom functions ?
• Was the MantisBT source code modified in any way ?

By the way, the only way there could be NULL for the mentioned query in this context, is if a tag's creator is 0, which can't happen with normal MantisBT operations - was the DB tampered with ?

Hi dregad. Thanks for the response. I upgraded and have the same problem. We are currently using mantisbt with db2. We currently have IBMi v7r1.

I dont know if the problem occurred because of the way in which we installed mantis. We had numerous problems installing mantisbt over db2 the standard way i.e using /admin/install.php so we applied a workaround by editing the install script(see attactment 'Mantis SQL Setup.sql')to install the tables manually. Then we created the config_inc.php with the necessary credentials. Also the zero in the line 'define('ADODB_FETCH_ASSOC',0);' was changed from 2 to zero from the file adodb.inc because users could not log in without this change.

So everything else works for mantis except for this manage tags problem.

The tag seems to have been created properly. The insert statement has a row id of 16 and all other values.

-PHP version: 5.2.17
-Zend Framework Version 1.11.10
-Mantisbt 1.2.11

I don't have any experience with DB2, and support for that is (very) limited, what we've got in the code has been contributed to by users like you who made it work.

That said- some comments:

• manually editing the script should be fine, as long as the final DB structure and contents is identical to what you'd get with a "normal" install
• messing with the ADOdb library's constants definitions is probably not a good idea. Not sure what kind of consequences this may have. You should probably set the fetch mode as appropriate in core/database_api.php instead.

Can you provide additional, debugging information:

1. temporarily configure your system as follows:

$g_show_detailed_errors = ON;

WARNING - SECURITY RISK: the 'show_detailed_errors' config can cause MantisBT to display sensitive information about your system. We recommend to restrict its activation to a Test environment, only for as long as necessary. If possible, do not turn it ON globally, instead limit it for specific user(s) using the Manage Configuration page.

2. Reproduce the error
3. save the output of the error screen, preferably as an HTML page
4. be careful to remove/mask any confidential information if needed
5. upload the results here

Hi dregad. I now think that the error is specific to db2 because i installed mantisbt on my local machine with the same settings but with mysql and it works okay.
However, i did the '$g_show_detailed_errors = ON;' like you suggested and uploaded the output 'manage_tags_page.php'.

Looking at the call stack, the error occurs because Mantis is trying to retrieve the id of a user whose name is NULL.

Can you look at the contents of mantis_tag_table, specifically the contents of the 'user_id' column. Are there any NULL values (maybe also check for '0's or empty strings) in there ?

The tag table seems fine. The newly created tag appears to have been inserted correctly. I've uploaded 'mantis_tag_table.png' to show this.

With regards to the error, as you may have noticed occurs because of the line: 'SELECT * FROM mantis_user_table WHERE id=null' from the file 'core/user_api.php' on line 57.

The last line in the mantis log is: 'SELECT *
FROM mantis_user_table
WHERE id=NULL',

When this is compared with the log on the local machine(the one using mysql instead of db2) for the same action the last line is: 'UPDATE mantis_user_table
SET last_visit= 1378127076
WHERE id=1'

So instead of a SELECT statement it has an UPDATE statement. I was thinking that the UPDATE statement made sense because it records the date/time last visit for this user, but the SELECT statement is a bit of a question mark.

You can't compare just the last statement from both logs, because in one case the whole operation went through, while in the other the process was interrupted by an error. If you look further up in your mysql log you should see the same select statement; its purpose is to retrieve and cache the user data, following a request to display the user's name, but that's not the root cause of the problem, just a consequence of it.

In your case I would expect to see 'SELECT * FROM mantis_user_table WHERE id=48'. The real question is, why do we get a NULL here instead, even though the DB has 48.

Please take a backup of manage_tags_page.php, then insert the following code right after line 110 (i.e. just before the '?>' tag):

var_dump($t_tags);

die;

Load the page, report the output here. Then you can restore the code.

Also, check in your SQL log, a query beginning with 'SELECT * FROM mantis_tag_table ...' and let me know what the actual full query is as well.

Hi dregad. We have found and implemented a workaround for this issue. We re-installed mantisbt but with mysql instead and linked mysql to the db2 through the ibmdb2i storage engine. So mantisbt works with db2 by replication. Thanks very much for all your replies and suggestions.

~Jailall~

Good to hear that you found a solution to your problem.

Nevertheless if you can spare the time and effort, it would be nice to go to the bottom of this issue and make mantis work with db2 natively.

Could you provide the info I requested earlier, and if needed execute additional troubleshooting instructions as well as perform some tests if needed?

Hi, dregad. This is the output from the vardump:

object(ADORecordSet_array)#20 (36) {

["databaseType"]=> string(5) "array"

["_array"]=> array(1) {

[0]=> array(6) {

[0]=> int(17)

[1]=> int(48)

[2]=> string(5) "Email"

[3]=> string(11) "Banks email"

[4]=> int(1378126159)

[5]=> int(1378126159)

}

}

["_types"]=> NULL

["_colnames"]=> NULL

["_skiprow1"]=> bool(false)

["_fieldobjects"]=> array(6) {

[0]=> object(ADOFieldObject)0000026 (3) {

["name"]=> string(2) "ID" ["max_length"]=> int(4) ["type"]=> string(3) "int" }

[1]=> object(ADOFieldObject)#25 (3) {

["name"]=> string(7) "USER_ID" ["max_length"]=> int(4) ["type"]=> string(3) "int" }

[2]=> object(ADOFieldObject)#24 (3) {

["name"]=> string(4) "NAME" ["max_length"]=> int(100) ["type"]=> string(6) "string" }

[3]=> object(ADOFieldObject)#23 (3) {

["name"]=> string(11) "DESCRIPTION" ["max_length"]=> int(1048576) ["type"]=> string(4) "clob" }

[4]=> object(ADOFieldObject)#22 (3) {

["name"]=> string(12) "DATE_CREATED" ["max_length"]=> int(4) ["type"]=> string(3) "int" }

[5]=> object(ADOFieldObject)0000021 (3) {

["name"]=> string(12) "DATE_UPDATED" ["max_length"]=> int(4) ["type"]=> string(3) "int" }

}

["canSeek"]=> bool(true)

["affectedrows"]=> bool(false)

["insertid"]=> bool(false)

["sql"]=> string(73) "SELECT * FROM mantis_tag_table ORDER BY name FETCH FIRST 20 ROWS ONLY "

["compat"]=> bool(false)

["dataProvider"]=> string(3) "db2"

["fields"]=> array(6) {

[0]=> int(17)

[1]=> int(48)

[2]=> string(5)

"Email" [3]=> string(11) "Banks email"

[4]=> int(1378126159)

[5]=> int(1378126159)

}

["blobSize"]=> int(100)

["EOF"]=> bool(false)

["emptyTimeStamp"]=> string(6) " "

["emptyDate"]=> string(6) " "

["debug"]=> bool(false)

["timeCreated"]=> int(0)

["bind"]=> bool(false)

["fetchMode"]=> int(0)

["connection"]=> object(ADODB_db2)0000001 (88) {

["databaseType"]=> string(3) "db2"

["fmtDate"]=> string(7) "'Y-m-d'"

["concat_operator"]=> string(2) "||"

["sysTime"]=> string(12) "CURRENT TIME"

["sysDate"]=> string(12) "CURRENT DATE"

["sysTimeStamp"]=> string(17) "CURRENT TIMESTAMP"

["fmtTimeStamp"]=> string(13) "'Y-m-d-H.i.s'"

["replaceQuote"]=> string(2) "''"

["dataProvider"]=> string(3) "db2"

["hasAffectedRows"]=> bool(true)

["binmode"]=> int(1)

["useFetchArray"]=> bool(false)

["_bindInputArray"]=> bool(false)

["_genIDSQL"]=> string(21) "VALUES NEXTVAL FOR %s"

["_genSeqSQL"]=> string(53) "CREATE SEQUENCE %s START WITH %s NO MAXVALUE NO CYCLE"

["_dropSeqSQL"]=> string(16) "DROP SEQUENCE %s"

["_autocommit"]=> bool(true)

["_haserrorfunctions"]=> bool(true)

["_lastAffectedRows"]=> int(0)

["uCaseTables"]=> bool(true)

["database"]=> string(8) "B002BF21"

["host"]=> string(8) "B002BF21"

["user"]=> string(10) "MANTISUSR"

["password"]=> string(7) "XXXXXX"

["debug"]=> bool(false)

["maxblobsize"]=> int(262144)

["substr"]=> string(6) "substr"

["length"]=> string(6) "length"

["random"]=> string(6) "rand()"

["upperCase"]=> string(5) "upper"

["true"]=> string(1) "1"

["false"]=> string(1) "0"

["nameQuote"]=> string(1) """

["charSet"]=> bool(false)

["metaDatabasesSQL"]=> string(0) ""

["metaTablesSQL"]=> string(0) ""

["uniqueOrderBy"]=> bool(false)

["emptyDate"]=> string(6) " "

["emptyTimeStamp"]=> string(6) " "

["lastInsID"]=> bool(false)

["hasTop"]=> bool(false)

["hasLimit"]=> bool(false)

["readOnly"]=> bool(false)

["hasMoveFirst"]=> bool(false)

["hasGenID"]=> bool(false)

["hasTransactions"]=> bool(true)

["genID"]=> int(0)

["raiseErrorFn"]=> bool(false)

["isoDates"]=> bool(false)

["cacheSecs"]=> int(3600)

["memCache"]=> bool(false)

["memCacheHost"]=> NULL

["memCachePort"]=> int(11211)

["memCacheCompress"]=> bool(false)

["sysUTimeStamp"]=> bool(false)

["arrayClass"]=> string(18) "ADORecordSetarray"

["noNullStrings"]=> bool(false)

["numCacheHits"]=> int(0)

["numCacheMisses"]=> int(0)

["pageExecuteCountRows"]=> bool(true)

["uniqueSort"]=> bool(false)

["leftOuter"]=> bool(false)

["rightOuter"]=> bool(false)

["ansiOuter"]=> bool(false)

["autoRollback"]=> bool(false)

["poorAffectedRows"]=> bool(false)

["fnExecute"]=> bool(false)

["fnCacheExecute"]=> bool(false)

["blobEncodeType"]=> bool(false)

["rsPrefix"]=> string(13) "ADORecordSet"

["autoCommit"]=> bool(true)

["transOff"]=> int(0)

["transCnt"]=> int(0)

["fetchMode"]=> int(0)

["null2null"]=> string(4) "null"

["_oldRaiseFn"]=> bool(false)

["_transOK"]=> NULL

["_connectionID"]=> resource(1) of type (DB2 Connection)

["_errorMsg"]=> string(0) "" ["_errorCode"]=> int(0)

["_queryID"]=> resource(17) of type (DB2 Statement)

["_isPersistentConnection"]=> bool(false) ["_evalAll"]=> bool(false)

["_affected"]=> bool(false) ["_logsql"]=> bool(false)

["_transmode"]=> string(0) ""

["_error"]=> string(0) ""

}

["_numOfRows"]=> int(1)

["_numOfFields"]=> int(6)

["_queryID"]=> resource(17) of type (DB2 Statement)

["_currentRow"]=> int(0) ["_closed"]=> bool(false)

["_inited"]=> bool(true) ["_obj"]=> NULL ["_names"]=> NULL

["_currentPage"]=> int(-1) ["_atFirstPage"]=> bool(false)

["_atLastPage"]=> bool(false) ["_lastPageNo"]=> int(-1)

["_maxRecordCount"]=> int(0)

["datetime"]=> bool(false)

}

EDIT (dregad): formatted

Here is the select statement for mantis_tag_table:

0 => 'SELECT * FROM mantis_tag_table
ORDER BY name',
1 => '0.1003',
2 => 'tag_api.php:239 tag_get_all()',

Thanks for the update. So it would appear that ADOdb library is returning the correct User ID (as expected).

Can you try adding

var_dump($t_tag_row);

Here's the vardump:

array(6) { [0]=> int(17) [1]=> int(48) [2]=> string(5) "Email" [3]=> string(11) "Banks email" [4]=> int(1378126159) [5]=> int(1378126159) }

Ok i think i get it, the problem is likely due to the adodb fetch mode, the returned array is numerically indexed but mantis expects an associative array with field names as keys.

I need to look into the code to make sure what the best solution is, but it shouldn't be too hard to fix in any case.

I'll let you know if more testing is needed.

ok. please let me know if you fixed the problem.

The attached changesets should fix the issue, which was in fact a regression introduced by 0013446.

The patch will probably apply cleanly on top of 1.2.15, but in case it does not, you can download a nightly build (make sure date >= 07-Sep-2013).

Please test and let me know the results, reopen the issue if the problem persists.

Hi i modified the three files in the changesets list:

-> mod - api/soap/mc_tag_api.php
-> mod - core/tag_api.php
-> mod - manage_tags_page.php

But i got a error when i clicked on the manage_tags_page link:

=> Fatal error: Call to undefined function require_api() in /www/sitesdirectory/htdocs/mantisbt1.2.11/manage_tags_page.php on line 41

Line 41 is:

-> require_once( 'core.php' );

Sounds like not only you replaced the whole files instead of just applying the patch, but you also copied the file from the 'master' branch changeset; you should take the ones from 'master-1.2.x'.

ok im not sure how to 'apply' the patch. I thought i was supposed to replace the files.

Get the patch from [1] and apply it as described in [2].

[1] https://github.com/mantisbt/mantisbt/commit/0d9c5e799ce58a8632678979e395025a0ebeb0ec.patch
[2] http://stackoverflow.com/questions/3418277/how-to-apply-git-diff-patch-without-git-installed

Hi dregad. Sorry for the late response. I was busy with other work.

So i applied the patch to the files, but there still seems to be a bug.
When i click on the manage_tags link, the page loads now but no data from the tags table shows up.

Note: we do have a tag entry in the tags table.

Also when i click on the 'create tag' link nothing happens.

I have uploaded 'no_tags.png' to show this.

I did a vardump after the lines:

-> # Retrieve Tags from table
-> $t_result = tag_get_all($t_name_filter, $t_per_page, $t_offset);

and i got: NULL

I think i made a stupid mistake in the code, can you try replacing '$t_result' by '$t_tags' at line 111 in manage_tags_page.php

I made the correction. The tags operations seems to be working fine now.
Thanks.