Sorry this is a SQL issue, not webpage
Please, update it

Thank you

I had this error but resolved it with a change to the table. If I recall correctly, I had to switch the field login_count to type int.

login_count in mantis_user_table is already an int

David, i assume it's you that emailed me..

I'm trying to think as I think i've seen this before -

what adodb driver are you using ?

i've got a sneaky suspicion that when i was looking at mssql support either the ado_mssql or odbc_mssql started behaving craply, although I believe that was fixed in adodb 4.60 (which we currently bundle)

401 isn't a 'field missing' error as i originally thought, but more a SQL failure of some description.

My db_type is mssql, neither ado_mssql nor odbc_mssql

I think that many problems could be resolved with a correct DB schema... that's the reason I would put a .sql file in install dir instead of trying a .php script

A .php script is a good idea, but it should be used later

If you have CVS access, there is a new admin/install.php script that aims to unify creating the database in all engines. Feedback would be welcome.

hi David,

The intention that i'm going to be putting forward is:

1. to deprecate:
   mssql.sql
   pgsql.sql
   db_generate.sql

2. Replace *.sql with install.php + schema.php

3. Look at having an install.php option to generate 'raw sql code' to text from schema.php for people that can't use install.php for some reason.

Paul, could you either work on this or mark it as resolved?

Jeroen,
The installer (install.php) already does item 3. We just need to delete the SQL directories.

Yes, I saw that functionality, I was just wondering whether the query was still giving problems.

As for removing the directory, cvs up -P should do that, right? The files appear to have been removed.

I believe that this issue can be resolved. I use mantis with some form of mssql at work, without issue.

Davide - do you still have this issue ?

Paul

Try to use a newer PHP version and set the used user to default language english.

I had the same issue with PHP 5.0.3 after upgrade to PHP 5.1.2 it works for me.

@mantis team. Could you create an /doc/mssql.txt to dicribe this probelem.

(Adding this note to 0005544, 0005904 and 0006063 - new here and hoping I'm not violating a policy - just trying to be helpful.)

I had same problem (and error 401). Via SQL Profiler captured this query:

INSERT INTO mantis_project_file_table
(project_id, title, description, diskfile, filename, folder,
filesize, file_type, date_added, content)
VALUES (0, 'asdf', 'asdf', 'd03303e4a04ef92ff2cbc13c64221566',
'20070111_Summary of FawnClient developments requirements 1v2.doc',
'', 60416, 'application/msword', '2007-01-27 05:32:39PM', 'ĐĎࡱ

... query ends with binary garbage from an unterminated quoted STRING which the
code is attempting to put into <content> field. The query string is, of course,
getting terminated prematurely by a random binary character value in the content
memory variable, and that's the source of the SQL error.

Seems to me this approach can't work because the only assumption you can make
about the content of the uploaded file is that it is binary, and of course
binary includes multiple byte/short values that can will be interpreted as
terminating UTF-8/UNICODE values that can and will randomly terminate the query
string prematurely.

I think the only metaphor that could accept binary data for an UPDATE statement would be that of a cursor based Recordset object where you can do something like
rs.getField("content").setBytes(byte[] byImageData), and then issue rs.update().

In 0006063, the user "rzg" makes the suggestion of using bin2hex() to convert
the binary data to hex. It seems to me that only an approach like that can be
guaranteed to generate a pure string value that can be concatenated into the
string query and delimited (quoted) without error. Perhaps, alternatively, an
attempt to escape non-printing chars... but that might be problematic with
multiple input languages.

If I may... I'd like to put forth the view that storing image data isn't a good
idea... Not trying to be critical, but two things...
1) A bin2hex() conversion or escaping approach requires more storage space than
the size of file; 2x for bin2hex() and maybe 1.4x for escaping (guesstimate).
2) There is the "SQL Injection Vulnerability" to worry about. I confess I did
not look deeply, but after a brief glimpse it looks like the implementation
deals with escaping single quotes entered into various free text fields to avoid
this. But after looking at file_api.php and database_api.php, I wonder if there
is a vulnerability here? I mean, if the content of the upload files is not
converted in some way, can't it inadvertently, or maliciously, cause an
injection?

I really think the only approach that makes sense is to use the
$g_file_upload_method = DISK option. I mean, file systems do a great job of
storing arbitrary file types, and databases do a great job of organizing data.
I'd just use the database to correlate objects in the file system hierarchy with
objects in the database.

Using "$g_file_upload_method = DISK" is how I resolved the issue here.

Doing a bit of tidyup on the issue tracker atm - 1.3.x when it gets released should have better support for mssql, especially now that MS have done some work on 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