The file_add() api function uses obsolete db_query() call instead of db_query_bound(); I will modify the code to call the new function (i.e. using bind variables) which hopefully will avoid the problem.

Hmmm it may not be as easy as I thought - seems there is an issue with adodb and db_query_bound for uploading the file contents (see attached screenshot), the 1st file is an upload with db_query_bound, while the 2nd is with the current code (db_query); files seem somehow "corrupted" (same test with a png file results in an unreadable image)

Please test a possible fix for this issue https://github.com/dregad/mantisbt/tree/oracle-fix-14563 and let me know your feedback.

Note that I have not performed tests on Oracle myself (only MySQL) as my dev Oracle DB is not operational at the moment.

Hi,

This commit causes that attachments are uploaded, size seems to be correct, but cannot be retrieved.

The bisect says

tgulacsi@unowebprd:~/mantis/tgulacsi$ git bisect good
4f4e69bd73e2840ce4542072bb544f51ddaf3cf7 is the first bad commit
commit 4f4e69bd73e2840ce4542072bb544f51ddaf3cf7
Author: Damien Regad damien.regad@merckgroup.com
Date: Thu Aug 9 14:52:39 2012 +0200

Use bind variables in file_add() function

Use of db_query() in file_add() is causing issues on Oracle due to the
size of literal SQL statements being limited to 2000 chars: error
ORA-01704 occurs when attaching files with DB storage. To avoid the
problem, bind variables must be used.

We now call db_query_bound() instead of db_query(), and file_add() has
been refactored to remove usage of deprecated db_prepare_* functions.

Fixes #14563

tgulacsi@unowebprd:~/mantis/tgulacsi$ git bisect log
git bisect start

bad: [a1a150cdb74f02f004b2f212d3a2aba98e8f37ad] Travis: only build for master and master-1.2.x

git bisect bad a1a150cdb74f02f004b2f212d3a2aba98e8f37ad

good: [bd6c4b950b3364dcedda032999afd172fbdcc599] Merge remote-tracking branch 'mantisbt/master-1.2.x'

git bisect good bd6c4b950b3364dcedda032999afd172fbdcc599

good: [2d50d42573b02b6d5a22af2532efa310d3250b81] Localisation updates from http://translatewiki.net.

git bisect good 2d50d42573b02b6d5a22af2532efa310d3250b81

bad: [5d088948b955d8989c0ef381112ce6f9f8226235] MantisCoreFormatting: Remove code duplication

git bisect bad 5d088948b955d8989c0ef381112ce6f9f8226235

bad: [1099ab515733a6b4f6a16613c02c7bf9d9ffae5a] IssueHistoryTest: fix failure when using descending order

git bisect bad 1099ab515733a6b4f6a16613c02c7bf9d9ffae5a

bad: [bcce7a2bd1c1ad3a6a981b5d5f42b9a0f1ac3451] Whitespace fixes

git bisect bad bcce7a2bd1c1ad3a6a981b5d5f42b9a0f1ac3451

bad: [4f4e69bd73e2840ce4542072bb544f51ddaf3cf7] Use bind variables in file_add() function

git bisect bad 4f4e69bd73e2840ce4542072bb544f51ddaf3cf7

good: [e1bee761b2e3357cfa0cc99268fd2abc887dbac1] Revised PHPdoc for file_add() function

git bisect good e1bee761b2e3357cfa0cc99268fd2abc887dbac1

good: [d63864faf605988571cae23c8b7928404d772046] Backport changes to file_add() function from master

git bisect good d63864faf605988571cae23c8b7928404d772046

Database is PostgreSQL 8.4.17

Good:
select id,bug_id,filesize, length(content) from mantis_bug_file_table where bug_id=1909 order by id desc;
id | bug_id | filesize | length
------+--------+----------+--------
3310 | 1909 | 18232 | 18232

Bad:
select id,bug_id,filesize, length(content) from mantis_bug_file_table where bug_id=1909 order by id desc;
id | bug_id | filesize | length
------+--------+----------+--------
3311 | 1909 | 18232 | 54101

Any ideas?

I'm not sure. I tested this successfully on my dev box, but I'm running a more recent release of postgres (9.1.9) and don't have access to 8.4.

I had to implement special handling of blobs (bytea) for 9.0+ support, see [1] - maybe the issue you're facing is similar.

[1] https://github.com/mantisbt/mantisbt/commit/49e413b436dd7aa1627710aa0c7376d7b354675d

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