View Issue Details

IDProjectCategoryView StatusLast Update
0023372mantisbtdb oraclepublic2017-10-04 05:20
Reportercproensa Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version2.7.0 
Summary0023372: error updating boolean fields
Description

This error happens in manage_user_update.php

ORA-01407: cannot update ("MANTIS"."M_USER"."PROTECTED") to NULL para la consulta: UPDATE m_user
SET username=:0, email=:1,
access_level=:2, enabled=:3,
protected=:4, realname=:5
WHERE id=:6

Also: manage_custom_field_update.php
More similar queries may exists

Fields defined as 'L', are used as on/off flags.
This datatype is mapped by adodb to some native type:

  • integer in mysql, oracle, etc
  • boolean in pgsql

When using a boolean parameter as value for updating such field, this value is not converted to proper native datatype.
This may be a bug with adodb, since it is mapping L to NUMBER(1,0), but not converting a boolean to the correct integer value.

However, one option is to reintroduce db_prepare_bool() function, which already takes care of this conversion.

TagsNo tags attached.

Relationships

related to 0019464 new update user or news info occurs error 

Activities

cproensa

cproensa

2017-10-02 15:03

developer   ~0057874

@dregad
https://github.com/mantisbt/mantisbt/blob/master/core/database_api.php#L329

Should we map all booleans to $g_db->true and $g_db->false?

dregad

dregad

2017-10-04 05:20

developer   ~0057889

This may be a bug with adodb, since it is mapping L to NUMBER(1,0), but not converting a boolean to the correct integer value.

Sounds like a bug indeed, as previously mentioned in 0019464:0049140. Do you mind opening an issue at https://github.com/ADOdb/ADOdb/issues/new for tracking and follow-up on ADOdb side ?

https://github.com/mantisbt/mantisbt/blob/master/core/database_api.php#L329
Should we map all booleans to $g_db->true and $g_db->false?

You mean in replacement of the for loop in db_query() ?
IMO that code is us trying to work around an issue that should be abstracted by the DB layer; using the ADOConnection $true/$false properties could make this workaround more generic, but at the end of the day I think it should be properly handled in ADOdb.