MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2014

Re: Question on using SQL2JXL in multiple concurrent jobs



fixed

Yes, that may be where I (we?) head eventually - it would give me a lot more flexibility -

But it'd be new enough to the group here, who knows how to do this other way - but I will definitely look into it - we have CGIDEV2 on board here.

This would get us away from limitations of SQL2JXL - only XLS output, it considers number format in a cell to be content, so it won't put in data above that - numeric types are always put in as General, and things like centering are lost.

Thx
Vern

On 7/2/2014 4:06 PM, Jon Paris wrote:
Another option of course is to use an XML template built from sample copy of the sheet(s) required. Split it into header, row and total sections etc. and then populate it and write to IFS.

I've done this using CGIDEV2, XMLi, and (before Henrik says it) powerExt. There are certainly other template based systems.

Generally faster than using the RPG <-> Java bridge.


On 2014-07-02, at 4:45 PM, Roger Harman <roger_harman@xxxxxxxxxxx> wrote:

Trying to "prettify" the result is a reason to move away from CSV.

But, I have a process that just took forever with a vendor product converting to XLS before running out of Java heap space. We wanted nice column headings and justification.

The fix was to output it as CSV but I retreive the column headings from SYSCOLUMNS for the first row so it presented that part nicely. Justification is still an issue but we're living with it for now.

This is such a common task - why does it seem so difficult to get a simple quick solution?



Date: Wed, 2 Jul 2014 16:25:05 -0400
Subject: Re: Question on using SQL2JXL in multiple concurrent jobs
From: gallium.arsenide@xxxxxxxxx
To: midrange-l@xxxxxxxxxxxx

On Wed, Jul 2, 2014 at 3:49 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
http://archive.midrange.com/rpg400-l/200703/msg00621.html
Note that the thread you're linking to talks specifically about moving
away from SQL2XLS to SQL2JXL, due to performance issues with the
former.

I think that such performance problems are quite common with utilities
which dynamically format the results of SQL queries into some other
format... particularly when Java is involved.
I don't think the "particularly when Java is involved" is a fair
assessment. Both SQL2XLS and SQL2JXL "involve Java". Yet SQL2JXL is
noticeably faster. The main thing that makes some POI-based solutions
slow is the RPG-to-Java interface. The more you have to call Java
from RPG, the bigger the overhead. Native Java is... well, not as
fast as pure C or pure RPG, but not as slow as Java-through-RPG.

And then of course there can be better and worse algorithms even
within one implementation language that can affect performance.

Have you considered streaming SQL result sets to .CSV instead?
Usually, CSV is one of the earlier ideas people come up with. Folks
turn to Excel mainly when CSV's shortcomings become deal-breakers.
But yes, if CSV is adequate, then it's a much faster-performing
solution.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com










Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact