Floating point values read error

[root-talis]

I'm developing a project that reads an ancient FoxPRO DB, converts it and pushes data into a MariaDB database. One of the former versions in 'dev-master' had possibility to decode floating point numbers correctly. Now something changed, and after 'composer update' instead of '8.0' I'm getting '6,3380589665485E-10'. Here is the file: SP_REF.ZIP. The column in question is 'STVREF'.

Unfortunately I cannot rollback to a previous stable version of php-xbase because of issue #21.

EDIT: here is the commit that introduces the error: 59ce03b

[ghost]

I think, the problem here is that some users used this code to read the data and some others to write the data. So, what is ok for some ones are not ok to the others. I also can not writing the types B, F and T. I then use N with decimalcount != 0 to write doubles.

[root-talis]

@letscape: I am trying to READ data from the cell.

[wardopdem]

Bug in file ...\src\XBase\Record.php, method Record.getObject, line 129:
case self::DBFFIELD_TYPE_NUMERIC:return $this->getInt($column->getName());

Type ('N') may be not only integer (in my case @'N33.4'): need analize this (length/decimalCount properties) and use getFloat/getDouble if it need.

Stuped quick-fix in Record.getInt may be something like that (for debug purposes only!):

// return intval($s);
if (($res = intval($s)) != $s) {
$res = doubleval($s);
}
return $res;

p.s. this bug probably is not connected with @root-talis problem - at the not corrected version get 8.0 at the both rows of the table...

[wardopdem]

See my pull request for more correct desigion.

[luads]

Great, thanks for that. I'm really short on time right now, so I hadn't had a chance to look at this issue.

[ghost]

There are another problem when we try to write a dbf here: https://github.com/hisamu/php-xbase/blob/master/src/XBase/Record.php#L295

Is caused by:

 $this->table->getColumn($columnName)

because of this:
https://github.com/hisamu/php-xbase/blob/master/src/XBase/Table.php#L233

The code create an intermediate table (a writableTable) inside the writableTable to write the dbf and is complex to see that the condition can not be satisfy in one of them: https://github.com/hisamu/php-xbase/blob/master/src/XBase/WritableTable.php#L49

Simple fix:

public function setObjectByName($columnName, $value)
    {
        if(array_key_exists($columnName, $this->table->getColumns()))
            return $this->setObject($this->table->getColumn($columnName), $value);
    }

[ghost]

This iteration is also inefficient:
https://github.com/hisamu/php-xbase/blob/master/src/XBase/Table.php#L225-L231
but yes is working...

[wardopdem]

Simple fix:

But this is masking problem and this is no good: if the field not found this is a error in client's code - exception need to be thrown (as is) for handling by the caller code - not silent.

[ghost]

@wardopdem true, that's why i don't opened a pull request.

[cerw]

@lestcape is this fixed now? I am getting same error from dev-master

[ghost]

@cerw I don't know, my solution was implement a python script (using a python dbf library) to migrate data to an special type of csv where columns headers contains the type and size(like they are display in libreoffice), then I call the script from php to do what i want (read or write data from/to the special csv). As a result, i have support for encoding data automatically. My dbf also can be read by default with VisualFoxPro, without asking for a charset or say that my dbf data is corrupted.

[ghost]

I'm trying to simplify my solution, migrating a probed Python library that works. Who want to help is here: https://github.com/lestcape/DbfPHP

[gam6itko]

I don't think it's still relevant