PhilDOakley
IS-IT--Management
I have found some interesting things while trying to import a very large amount of data (circa 350,00 csv lines as there are 2 lines of optional fields for each entry) into a GL journal batch as one entry from a CSV file.
The standard 300 GL journal import process never releases memory and eventually runs out at about 1.8gb. I think this is probably the upper limit for a 32 bit app.
So I decided to write a VBA macro to import the file and do it in smaller chunks. What I have found is the inital creating and import consumes all the memory. However, if I create the batch and then just add to it it does not consume nearly as much memory and apears to grow and then fall back. The imitial creation and import is fairly fast. The adding to an existing batch is very slow!
I wrote this using a VBA macro as it was the quickest way to test this. My intention is to move it over to c#.
The speed this runs at is probably going to mean this is not a viable solution and I do not want to invest the time in writing the c# option if it is going to be just as slow.
I feel there must be hope as the GL consolidation program imports large amounts of data into a GL journal and in a reasonable amount of time.
Has anyone got evidence that using the COMAPI is very slow and is there a better alternative that will yield a massive speed improvment?
The standard 300 GL journal import process never releases memory and eventually runs out at about 1.8gb. I think this is probably the upper limit for a 32 bit app.
So I decided to write a VBA macro to import the file and do it in smaller chunks. What I have found is the inital creating and import consumes all the memory. However, if I create the batch and then just add to it it does not consume nearly as much memory and apears to grow and then fall back. The imitial creation and import is fairly fast. The adding to an existing batch is very slow!
I wrote this using a VBA macro as it was the quickest way to test this. My intention is to move it over to c#.
The speed this runs at is probably going to mean this is not a viable solution and I do not want to invest the time in writing the c# option if it is going to be just as slow.
I feel there must be hope as the GL consolidation program imports large amounts of data into a GL journal and in a reasonable amount of time.
Has anyone got evidence that using the COMAPI is very slow and is there a better alternative that will yield a massive speed improvment?