Re: another string length problem

On Monday 25 June 2007, David Reiser wrote:
> ameritrade seems to have added some new proprietary tags that cause
> gnucash 2.x to crash in ofx_preproc.cpp similar to another string
> issue fixed last fall.
>
> Christian Stimming sent me the attached patch to test, and it does
> keep gnucash from crashing while importing the offending file.

I'm not sure the patch is correct.  I suspect it just masks the issue.  Can 
you send the test case that caused the crash?

--

-- 
Benoit Grégoire
Technologies Coeus inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Libofx-devel mailing list
Libofx-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libofx-devel

Re: another string length problem

On 3 Jul 2007, at 3:24:49 PM, Benoit Grégoire wrote:

> On Monday 25 June 2007, David Reiser wrote:
>> ameritrade seems to have added some new proprietary tags that cause
>> gnucash 2.x to crash in ofx_preproc.cpp similar to another string
>> issue fixed last fall.
>>
>> Christian Stimming sent me the attached patch to test, and it does
>> keep gnucash from crashing while importing the offending file.
>
> I'm not sure the patch is correct.  I suspect it just masks the  
> issue.  Can
> you send the test case that caused the crash?
>
> -- 
> Benoit Grégoire
> Technologies Coeus inc.

Attached is a short ofx file that crashes libofx 0.8.3  (under  
gnucash 2.1.x). Importing the file into the same version of gnucash  
does not crash if the libofx patch from cstim (proptagfix.patch in my  
june 25 email) has been applied to libofx. The indenting is mine (not  
Ameritrade's). The full file from which this is excerpted does not  
have the indenting. The behavior of the full file is the same -  
crashes existing libofx, does not crash with the patch.

My later musings regarding CUSIPs for the sweep account proved to be  
incorrect. Ameritrade did provide an entry in <seclist> early this  
year, but did not in my June downloads. The presence or absence of  

using libofx_request_statement() to get balance

I'm a new gnucash user and also new to aqbanking & libofx. I am
using FreeBSD and am creating updates to the FreeBSD ports to make
use of the latest versions of aqbanking & libofx. (It remains to
be seen if my updates will be accepted).

I think there should be a small change in the way
libofx_request_statement() works, so I'd like to propose it to
the more experienced people here to see if my idea makes sense.
I am mostly unfamiliar with libofx and aqbanking so maybe there
is a better approach.

Proposal: when libofx_request_statement() parameter date_from is 0,
the INCTRAN block in the request should be omitted.

In order to communicate with my (US) bank's system, I had to
incorporate the changes described at the bottom of
http://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect_in_GnuCash_2
to support the various account types, and I can get statements now
for my three types of accounts (checking, savings, money market)
via the aqbanking-tool command line.

When I request a balance of the checking account via either gnucash or
"aqbanking-tool request --balance", however, the bank takes more than
60 seconds to respond, and the client code times out. I traced this
problem to the way libofx_request_statement() is called:

When a "balance" is requested, date_from parameter is set to 0 and as
a result, records of all transactions starting at the beginning of time
are requested.  My bank takes longer than 60 seconds to assemble its
(huge) response (which is not needed anyway), so timeout occurs.

Re: another string length problem

> Attached is a short ofx file that crashes libofx 0.8.3  (under
> gnucash 2.1.x). Importing the file into the same version of gnucash
> does not crash if the libofx patch from cstim (proptagfix.patch in my
> june 25 email) has been applied to libofx. The indenting is mine (not
> Ameritrade's). The full file from which this is excerpted does not
> have the indenting. The behavior of the full file is the same -
> crashes existing libofx, does not crash with the patch.
>
> My later musings regarding CUSIPs for the sweep account proved to be
> incorrect. Ameritrade did provide an entry in <seclist> early this
> year, but did not in my June downloads. The presence or absence of
> the sweep account in the <seclist> does not affect this crash.

Thanks, 'ill take a look in the not too distant future.

--

-- 
Benoit Grégoire
Technologies Coeus inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Libofx-devel mailing list
Libofx-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libofx-devel

Re: using libofx_request_statement() to get balance

I wrote:

>aqbanking seems to call libofx_request_statement() with a 0 date_from
>when it doesn't want any transactions to be downloaded (i.e., when it
>wants just the balance): see the function AO_Provider_RequestStatements()
>in aqbanking/src/plugins/backends/aqofxconnect/plugin/provider.c
> 
>Should date_from==0 mean "get balance only and no transactions", i.e.,
>omit <INCTRAN> ? 

Now that I have dug around a little more, my understanding is better,
and it is clear my earlier proposal is flawed. (And I learned I could
control aqofxconnect recvTimeout in .banking/settings.conf)

I believe the current libofx API allows the caller to request a
statement with transactions included starting at a specified time:

    CFCT char *
    libofx_request_statement(
        const struct OfxFiLogin* fi,
        const struct OfxAccountInfo* account,
        time_t date_from );

I would like some additional control over the request:

    1. Allow to omit the transactions because they should not
       be included when the caller only wants a balance.

    2. Allow caller to specify an end time for transactions just
       like we can now specify start time. This would allow