Money field can't handle BIG values

Such big amounts haven't been tested a lot I'm afraid, no. Will have a look at it when I find the time, which is probably in the beginning of July. If you want a solution faster, I'm afraid you'll have to look for the cause yourself. First look at MySQL, that column might be declared too small.

The problem is not only in Money CCK field module. It is in bad type handling in content.module and databace.inc of D5 core.

This is how value braking occures:

1) First in _money_amount_to_integer() function in money.module we have:

....
$converted_amount = (int) ($converted_amount + 0.01);
...

which converts BIGINT value (13 bytes) to PHP platform dependent INT (4 bytes usually). One.

2) Then in content_field() function in content.module we have:

...
case 'int':
case 'mediumint':
case 'tinyint':
case 'bigint':
$column_placeholders[] = '%d';
$column_assignments[] = $attributes['column'] .' = %d';
...

which assings the same %d placeholder both to int, tinyint and bigint. Two.

3) As the result, since in _db_query_callback() function in database.inc we have:

...
case '%d': // We must use type casting to int to convert FALSE/NULL/(TRUE?)
return (int) array_shift($args); // We don't need db_escape_string as numbers are db-safe
...

we get big problem with all big values. Three.

============

I'm sorry, dont want to be rude, but handling money values as platform dependent integers is not even funny.

My quick unsafe fix (almost not tested, just applied):

1) money.module. Comment out the line:

$converted_amount = (int) ($converted_amount + 0.01);

2) content.module. Add bigint processing in 'update' section with fallback to '%s':

case 'bigint':
$column_placeholders[] = '%s';
$column_assignments[] = $attributes['column'] .' = %s';

Sorry for the extremely slow reply and … no offense taken :)

I'm afraid I'll have to wontfix this issue then… This is a bugfix-only branch as of now and I doubt CCK/core will want to apply these changes. The problems are probably gone in Drupal 7's new DB layer, but you may want to verify that. You can also post a patch for the DB layer in D6 if the problem exists there as well.

Sorry that I can't be of more help here.