> -- a 450k files took (n) minutes to translate
> -- a 4500k file took 55 x (n) minutes to translate
> I can't answer why a file 10x larger took 55x more time to
>translate.
We use MS SQL server backend for Gentran. I had a MS SQL guru here tracing Gentran's SQL statements. His comment was that gentran was using "Ad Hoc" SQL statements which I took as meaning that they were using totally generic SQL statements to support as many flavors of backend databases as possible. The tradeoff is performance. It didn't seem that there was any optimization to the database. It used very little if any indexing. Thus it seems that the more documents per batch, the larger the database table for that batch and thus efficiency goes way down as the table takes more time to move through.
There was some rumor from Sterling that awaited version 3.0 would have an MSSQL optimized version of the program, but I can't pin them down on this. Some employees say yes, some say no.
Interestingly, Bob, I sent them a 27 meg file, that defied error diagnosis and said - "Here, you prove to me that you product can do the job for me". They escalated it to Level 2 tech support. In a couple follow up calls, I told the Level 1 Techs that I know what the compliance error is and I'll tell them if they would like to know. Both the level one guys said "No, lets let Level 2 figure it out - they need to address this shortcoming. You're not the first one to complain about this."
Very interesting.
I had already gone your route and wrote a transaction segmenter, but I noticed a small bug in my script that didn't always provide a perfectly divided segment, so I decided not to invest any more energy patching a sinking ship and simply to find another translator.
Regarding Archive crashing - another capacity related issue, they want me to install these debug symbol and diagnose the error for them, but I haven't had time yet. Different people in the company seem to admit or deny this issue, so there's no consistent call on that play.
Anthony
-----Original Message-----
From: Bob Garbowitz [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 10, 2000 8:37 AM
To: [EMAIL PROTECTED]
Subject: Re: EDI & ANY to XML translator - opinions wanted
<snip>
> We're currently using Gentran:Server NT and we have reached a limit with
> this tool.
> Some of our incoming batches are too large (20 - 30 Megs) for this
> translator to handle efficiently.
> It will translate them eventually, if they are 100% compliant, however if
> your batch has
> a syntax error or standard violation, gentran can't effectively diagnose
> the error.
> We find all of the database activity really slows down this translator as
> well.
>
> Thanks
> Anthony Beecher
> EDI Analyst
<snip>
Possible temp fix until you get different software:
I regularly translate batches of up to 50 meg using Gentran and this
is a problem. One characteristic of Gentran is that it translates at a
faster rate if the batches are smaller. Using the same transactions and
maps I found the following.
-- a 450k files took (n) minutes to translate
-- a 4500k file took 55 x (n) minutes to translate
I can't answer why a file 10x larger took 55x more time to
translate. Neither could Gentran support. It doesn't appear to be a RAM
limit or other hardware issue.
Since my applications allow it, I wrote scripts that feed Gentran
incremental batches of not more than 1 meg at a time. Some of my
transactions may be 2 or 3 megs each so I cannot split those, but feeding
Gentran bite size chunks speeds things up. In the example above, I
translate 10 batches of 450k instead of 1 batch of 4500k. It takes about 10
x n instead of 55 x n to translate.
This is a pain, but it is the only way I can keep traffic flowing.
...Bob
====================
Bob Garbowitz
Director of Technology
Beverage Data Network
110 Fairview Ave.
Verona, NJ 07044
Tel - (973) 239-1400 x104
Fax - (973) 239-1437
====================
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
