I'm sorry to bother if I'm wrong, but I don't think it's a duplicate of 0005717 or 0005691 because it's before login not after login.

Note:
I've sucessfully installed mantis on
a) PHP 4.3.3 and MySQL 4.0.15-max-debug
b) PHP 4.3.11 and MySQL 3.23.58-log

for these 2 platform I have no 0005729 problem but I've got 0005691 issue so I've download and installed the patch from cvs successfully

but for my last platform
c)PHP 4.3.10 on MySQL 4.0.22
I can't even got login page so IMHO it's a different bug.

Could you turn $g_show_detailed_errors = ON; and post more details of the error. The one you listed is a generic SQL command failed message.

It doesn't show up any information!
Perhaps because it's a fatal error so it's not trapped!

it occurs in function "db_query" in core/database.api

fawlty code

    if ( !$t_result ) {
        db_error($p_query);
        trigger_error( ERROR_DB_QUERY_FAILED, ERROR );
        return false;
    }

error is on trigger_error function
I've manually added a print($p_query) and it shows:
SELECT id FROM mantis_user_table WHERE cookie_string=''SELECT id FROM mantis_user_table WHERE cookie_string=''

result:
1) select statement is executed twice
2) cookie_string is empty (i don't know if it's relevant)
3) but why it doesn't trigger the error properly let me confused

There seem to be two problems here.

The first, which I am fixing, is that the query should not be made with a blank cookie string.

Second, the database query shouldn't fail in this case. It should just return no rows, unless the database table is missing. Was the database created according to the installation instructions?

Yes the database was created according to the installation instructions
and in fact the query don't fail when I run it on phpMyadmin interface and yes it returns no rows.

Partial fix submitted to CVS. A blank cookie is now considered invalid.

core/authentication_api.php -> 1.50

Could you patch this module from CVS and retest?

It's better but there are still some problems, I've uploaded the result page

In fact, after some others tests, I've detected that I haven't filled
$g_database_name which seems to be necessary even if for my personal website hosted on the same server I don't fill it.

But very stange admin/check.php doesn't show any errors related to this.

I have even tried to enter some scrappy username or hostname and admin/check.php doesn't show any errors.

In conclusion, bug is fixed for me if I enter $g_database_name even if it shouldn't be necessary, but admin/check.php doesn't detect all configuration problems related to database.

Resolving for now.

With new install code in CVS HEAD, this should be less of an issue, as install.php will detect it when trynig to create a DB.

We do however need to be careful of the current organisation of install.php/check.php checks.