[GNC] OFX import sometimes loses transaction memos

[Geert Janssens]

Op donderdag 17 januari 2019 06:33:25 CET schreef David Carlson:
> I think that I need to spend more time examining the transactions that had
> their memos dropped during import to see if I can find a threshold string
> length, then file a bug report asking for a short term fix truncating
> strings rather than dropping them, and a long term fix accepting up to the
> 256 character max and truncating after that.
> 
> David C

I don't think there should be one. Some time back I submitted a number of 
patches to handle long strings in the ofx library. IIRC it internally uses a 
fixed-length buffer to read parts of the ofx file. And I believe that buffer 
itself was already 1024 characters long. So at least for lines (including 
tags) of that size there should not be a problem. Next if the buffer gets full 
before a full tag contents could be read, it simply fills that buffer a second 
time and appends that contents to the same first string. So in principle you 
can have text messages of unlimited size.

Now there were bugs in that area, and my patches were partly to resolve those. 
IIRC one issue was if the ofx file didn't have newlines between tags that 
buffer handling would not always work as it should.

Note those changes have gone into a recent libofx release. As it's been a 
while I don't know whether gnucash 2.6.x was ever packaged for Windows with 
this more recent release though I'm sure gnucash 3.x is.

And of course there may be other bugs that weren't reported yet. I'm not using 
ofx myself.

Lastly it's probably still interesting to run ofxdump as it can help determine 
whether the issue already starts in the libofx library or rather that gnucash 
messes up the data it received from libofx.

Regards,

Geert