Seems I found a solution, however it is definitelly db vendor specific. I needed to add "to_char" function for the "value" column before comparing with the second parameter. Now it worked and I was able to remove categories.

However, I do not know the limitations of "to_char" function if I do not lose any longer values...

Please, if you can check this situation and confirm my suggested solution or bring some better. Thanks.

MSSQL/Oracle support is known broken in the 1.2 releases.

We plan on replacing the database API after the 1.3 release to try to provide proven support for other database platforms moving forward.

For now, I'd suggest for best results using mantis with MySQL

Please confirm if this issue is reproducible using a nightly build of 1.3 ("master") branch [1]

[1] http://mantisbt.org/builds.php

MantisBT currently supports Mysql and has support for other database engines.

The support for other databases is known to be problematic.

Having implemented the current database layer into Mantis 10 years ago, I'm currently working on replacing the current layer.

If you are interested in using Mantis with non-mysql databases - for example, Oracle, PGSQL or MSSQL, and would be willing to help out testing the new database layer, please drop me an email at paul@mantisforge.org

In the meantime, I'd advise running Mantis with Mysql Only to avoid issues.

Thanks
Paul

Dear Paul, I would gladly help with testing or even developing the fixes for other databases but I can hardly found time for it. Therefore, I had just solved the problems locally and will wait for some new versions.

Recently came across this error with MSSQL2012. Updated the following line in manage_proj_cat_delete.php:
$t_query = 'SELECT count(config_id) from {config} WHERE config_id = ' . db_param() . ' AND value = ' . db_param();

to

$t_query = 'SELECT count(config_id) from {config} WHERE config_id = ' . db_param() . ' AND value LIKE CONVERT(VARCHAR, ' . db_param() . ')';

I am now able to delete categories without an error.

Thanks for your update, which tells us the problem is not Oracle-specific (since you're using MSSQL) and also that it affects 1.3.x as well as 1.2.x.

I had a quick look at the code, and I believe that converting the parameter's type at SQL level is not the right approach.

$f_category_id is of type int, but the config table's config_id column is defined as VARCHAR(64). It would therefore make more sense to cast it to string

See proposed fix in PR https://github.com/mantisbt/mantisbt/pull/726 - kindly test and let me know if that resolves the problem.

The proposed fix did not resolve the problem. I still receive the error when casting $f_category_id as a string.

I agree that changing the parameter type at the SQL level is not the right approach, but the problem in MSSQL is that the value column is TEXT and the original code was passing the second parameter as an INT.

$t_default_cat_count = db_result( db_query( $t_query, array( 'default_category_for_moves', $f_category_id )));

So we received a MSSQL error of "Operand type clash: text is incompatible with int.

So your next suggestion was the following code which pass the second parameter as a STRING.

$t_default_cat_count = db_result( db_query( $t_query, array( 'default_category_for_moves', (string)$f_category_id )));

Now we receive a MSSQL error of "The data types text and varchar are incompatible in the equal to operator.

Thanks for the feedback. I'm sorry, for some reason I thought the column was defined as VARCHAR - I should have checked the schema definition.

The problem is, there is no clean, portable way to do this at SQL level because the type cast is DB-specific (e.g. TO_CHAR in Oracle, CONVERT in MSSQL, CAST in PostgreSQL, etc).

Since we're only interested in the record count, another approach could be to execute a query to retrieve all config table records for 'default_category_for_moves', and then check how many we got - if 0 then we can delete.

I'll work on that alternative implementation later.

Updated PR https://github.com/mantisbt/mantisbt/pull/726 - please test.

Confirmed working for both 1.3.0-rc1 and 1.3.0-rc2-dev master-2a92f07 with MSSQL 2012. Thanks for the support!