Can't read Memo type from Foxpro

[corentin-pasquier]

Hi,

I'm iterating through a FoxPro database and one of the columns is of type 'memo'.
It seems xbase has a problem with this data type : printing the value shows a question mark inside a black diamond.

Do you have a solution or is it a known problem that will be fixed one day ?

Thank you,
Corentin.

[chetstriker]

Also having same issue. Well, mostly. I get random info like å�201008 instead of a readable paragraph.

[scottsb]

This looks like a character encoding issue. Did you specify the correct encoding when instantiating Table?

[lenochware]

I have same problem. I am creating table as:

$table = new Table('./files/TABLE.DBF', $columns, 'cp1250');

Data readed from table (not memos) are ok.

[adixon]

I've reproduced this, and it seems there are two issues here:

1. The memo field pointer is 4 characters instead of 2 (so need to convert to a long integer).
2. The code is doing the iconv on the pointer string (oops!).

PR submitted #63

[PeterCrea]

A little follow up on this with a related problem that I had with the current version of the library.
When a table is of type 0xF5 (245) (=FoxPro with memo FPT file), the method getMemo() checks if the length of the data is 2 and then reads a signed 16-bit integer. However, a field of type M is always of length 10 and contains a numerical representation as text of the pointer to the block in the memo file.

This change in Record.php to the getMemo method makes it work (changes in bold):

public function getMemo($columnName)
{
$data = $this->forceGetString($columnName);
if($data && $this->table->version==0xF5) {
$pointer=intval($data);
return $this->memoFile->get($pointer);
}
else if($data && strlen($data) == 2) {
$pointer = unpack('s', $data)[1];
return $this->memoFile->get($pointer);
} else {
return $data;
}
}

In fact, according to the unofficial 'specs', a memo-field of type 'M' is never 2 bytes long so I'm not sure where that comes from. This might also be true for other table types with memo-files, so it might not be limited to type 0xF5, but all my files are of this type.

[gam6itko]

Same here #75

[gam6itko]

Does anyone have a file to reproduce the bug?

[gam6itko]

Perhaps this was fixed in 1.1.0. I close the issue because i have no data to reproduce the bug.