got this working myself changed in file_api.php :

        case DATABASE:
            $c_content = db_prepare_string( fread ( fopen( $p_tmp_file, 'rb' ), $t_file_size ) );

to
case DATABASE:
$c_content = fread ( fopen( $p_tmp_file, 'rb' ), $t_file_size

and also the following line:

    $query = "INSERT INTO $t_file_table
                    (" . $p_table . "_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, content)
                  VALUES
                    ($c_id, '$c_title', '$c_desc', '$c_disk_file_name', '$c_new_file_name', '$c_file_path', $c_file_size, '$c_file_type', " . db_now() .", '$c_content')";

to

$query = "INSERT INTO $t_file_table
(" . $p_table . "_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, content)
VALUES
($c_id, '$c_title', '$c_desc', '$c_disk_file_name', '$c_new_file_name', '$c_file_path', $c_file_size, '$c_file_type', " . db_now() .", 0x". bin2hex($c_content) .")";

updated the php.ini file and set mssql.textsize = 2147483647 and mssql.textlimit = 2147483647 (these values may be a 'bit' too large but it did the trick, besides php upload limit will also reject larger files). The purpose of setting those values is that else only the first 4096 bytes get stored in the server. Couldn't do this with ini_set('mssql.textsize','2147483647').

The bug_api.php also has an file upload routine, but i don't think it's being used, else it probably should also be updated.

See 0006063. We came to the same conclusion/patch.

As of 1.1.0a2 this is still an issue and RogierB's fix still works. Don't forget to change mssql.textsize and mssql.textlimit.

It is still an issue in version 1.1.8.
I Got the message below when I compressed a Charles file .chls with winrar. I got the same problem when I tried to upalod it uncompressed. After the strange symbols I see the binary data.

atabase query failed. Error received from database was 0002006: MySQL server has gone away for the query: INSERT INTO mantis_bug_file_table
(bug_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, content)
VALUES
(1744, '', '', 'fd2384f6ad0807858aaf9c91f75ea6b7', 'FindRide_Company.rar', '', 1158832, 'application/x-rar-compressed', '2009-12-28 11:30:20', 'Rar!\Z\0ϐs\0\0\r\0\0\0\0\0\0\0��t�:\0[�\0�0\0�\�s�X�;5\0 \0\0\0FindRide_Company.chls\0�a
P�����0Ԡ\"\"�\"��~
�f.................

There have been several changes in file upload mechanism since version 1.2, as well as in the ADOdb abstraction layer module for mssql.

Please check if problem is still reproducible using a nightly build >= 18-Aug-2012, and report any issues you may encounter.

@degrad, I will test this as soon as I get a chance, good job. (Luckily we are still using mantis bt after 6 years :) )

Marking as Suspended

MSSQL support is currently known broken. We are going to be replacing the DB Layer in Mantis to fix this properly after the next release.

I'd strongly advise using MYSQL for now.

The new DB layer already contains the appropriate fixes for MS SQL Support.

MSSQL support is currently known broken. We are going to be replacing the DB Layer in Mantis to fix this properly after the next release.

I'd strongly advise using MYSQL for now.

The new DB layer already contains the appropriate fixes for MS SQL Support.

Is the release schedule for the new DB layer for MSSQL available?

Dcoomber,

I plan to have completed testing of the new DB layer with MSSQL at some point over this weekend.

Would you be interested in helping to test the new layer?

Paul

Paul,

I am willing to assist with testing of the new FB layer.

If possible, please PM me and we can discuss further.

David

Hi guys,

We have also got around the attachment issue in MSSQL with the latest version of mantis by altering the following:

Change these lines in core/file_api.php:

$query = "INSERT INTO $t_file_table
( $t_id_col, title, description, diskfile, filename, folder, filesize, file_type, date_added, content, user_id )
VALUES
( " . db_param() . ", " . db_param() . ", " . db_param() . ", "
. db_param() . ", " . db_param() . ", " . db_param() . ", "
. db_param() . ", " . db_param() . ", " . db_param() . ", "
. db_param() . ", " . db_param() . " )";
db_query_bound( $query, Array(
$t_id,
$p_title,
$p_desc,
$t_unique_name,
$t_file_name,
$t_file_path,
$t_file_size,
$p_file['type'],
$p_date_added,
$c_content,
(int)$p_user_id,
) );

Remove $c_content from the Array() and put it directly into the query parameters:

$query = "INSERT INTO $t_file_table
( $t_id_col, title, description, diskfile, filename, folder, filesize, file_type, date_added, content, user_id )
VALUES
( " . db_param() . ", " . db_param() . ", " . db_param() . ", "
. db_param() . ", " . db_param() . ", " . db_param() . ", "
. db_param() . ", " . db_param() . ", " . db_param() . ", "
. $c_content . ", " . db_param() . " )";
db_query_bound( $query, Array(
$t_id,
$p_title,
$p_desc,
$t_unique_name,
$t_file_name,
$t_file_path,
$t_file_size,
$p_file['type'],
$p_date_added,
(int)$p_user_id,
) );

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

The issue still exists and is due to an unnecessary varbinary/image encoding intended for inline queries. I examined all (4) instances of db_prepare_binary_string() calls, and in all cases the return value is now used in parameterized queries (i.e. with db_param()). Because of this, no encoding is necessary at least for the mssqlnative driver, and very likely for others as well.

I do not know if such encoding is necessary for PostgreSQL, but I propose to actually make the db_prepare_binary_string() function a no-op for the time being, until any broken use cases emerge. As it stands, this function appears to hurt more than it helps. If not made a no-op, then the function would need to be split down the road into two variants: one for inlined query values, and one for parameterized queries.

Attached here is the minimal patch needed for mssqlnative.

diff -ur -U 5 mantisbt-1.3.0-beta.3\core\database_api.php mantisbt-1.3.0-beta.3-mspl1\core\database_api.php
--- mantisbt-1.3.0-beta.3\core\database_api.php	Sun Sep 06 14:10:14 2015
+++ mantisbt-1.3.0-beta.3-mspl1\core\database_api.php	Tue Sep 08 14:03:14 2015
@@ -802,11 +802,12 @@
 	global $g_db;
 	$t_db_type = config_get_global( 'db_type' );
 
 	switch( $t_db_type ) {
 		case 'mssql':
-		case 'mssqlnative':
+		# XXX: Is this function even needed now? All of its instances are used in parameterized SQL queries (db_param())
+		#case 'mssqlnative':  # Definitely do not need to encode varbinary in parameterized SQL queries with MS sqldrv v3.2 (php_sqlsrv_56_nts.dll)
 		case 'odbc_mssql':
 		case 'ado_mssql':
 			$t_content = unpack( 'H*hex', $p_string );
 			return '0x' . $t_content['hex'];
 			break;

Thanks for the research. I'll test this with PostgreSQL.

I believe this was fixed in 0022208. Closing as duplicate.