IMPORTANT:
this is not a Support Forum! Experienced users might answer from time to time questions posted here. If you need a professional and reliable answer, or if you want to report a bug, please contact Altova Support instead.

GS segment return wrong time in F337 Options · View
Waqar
Posted: Wednesday, November 4, 2009 11:34:02 AM
Rank: Member

Joined: 4/24/2006
Posts: 11
Location: USA
Hi,

I am creating Database to X12 857 file. But system generating 9 digit content which exceed maximum 8 digit lens.

Line 2 column 29 (offset 0x88): The content of 'F337' is longer than the maximum length of 8 characters: '202754906'

Any idea how to fix it?
rip
Posted: Wednesday, November 4, 2009 11:43:09 AM
Rank: Advanced Member

Joined: 7/17/2008
Posts: 185
Location: Minutiae, Triviality
Sure, he said, jokingly,

substring(.,1,8)

but that is probably not what you want.

F337 looks like time, based on the random year group 857 file I pulled up. Time is 8 characters, probably HH:MM:SS

What is 202754906? Seconds since epoch?


Waqar
Posted: Wednesday, November 4, 2009 12:00:08 PM
Rank: Member

Joined: 4/24/2006
Posts: 11
Location: USA
rip, i didn't assign anything to this field system automatically generate this information.
do i assign time from library to this field?
rip
Posted: Wednesday, November 4, 2009 12:05:50 PM
Rank: Advanced Member

Joined: 7/17/2008
Posts: 185
Location: Minutiae, Triviality
aha, ok, now that is the kind of interesting information that would have been very very helpful in the first post, sadly it was buried in my misinterpretation of what you meant by "system". "Auto-complete" would have been a better choice, assuming you don't have anything connected to the F337. Can you show us the mapping?

A test using Altova's example files for 850, disconnecting the F337 connections, doesn't get me anything that looks like a nonsense value
  • .

    Short term, try connecting a zero-length constant to the F337 connector, which will defeat any auto-complete that might be happening.

    what do you get?

    edit:
  • because I was looking in the wrong place. Doh.
  • Waqar
    Posted: Wednesday, November 4, 2009 12:16:15 PM
    Rank: Member

    Joined: 4/24/2006
    Posts: 11
    Location: USA
    rip wrote:
    aha, ok, now that is the kind of interesting information that would have been very very helpful in the first post, sadly it was buried in my misinterpretation of what you meant by "system". "Auto-complete" would have been a better choice, assuming you don't have anything connected to the F337. Can you show us the mapping?

    A test using Altova's example files for 850, disconnecting the F337 connections, doesn't get me anything that looks like a nonsense value.

    Short term, try connecting a zero-length constant to the F337 connector, which will defeat any auto-complete that might be happening.

    what do you get?

    Rip, do i take screen shoot or how i show mapping here.
    Another funny think i just discover, sometime time is 8 character long and sometime 10 :(, it is bit weird.
    Let me try your other advise.

    Ok zero length constant showing this
    Source-value '' of type string could not be converted into target-type time.
    rip
    Posted: Wednesday, November 4, 2009 12:18:42 PM
    Rank: Advanced Member

    Joined: 7/17/2008
    Posts: 185
    Location: Minutiae, Triviality
    now that you've posted, come back to your post and you'll find a "attachment" button on it. Click that, follow steps. See option two of this post for more information.
    rip
    Posted: Wednesday, November 4, 2009 12:25:01 PM
    Rank: Advanced Member

    Joined: 7/17/2008
    Posts: 185
    Location: Minutiae, Triviality
    interesting.

    "" gives that message, "12:14:16" results in "121416" in the output file, but when I don't connect anything at all, I get 14215735.

    hm hm hm. interesting.

    seems to contradict this page (very bottom) as 14215735 isn't ISO 8601 I don't think.

    You should file this with Altova support I think.

    rip
    Waqar
    Posted: Wednesday, November 4, 2009 12:30:19 PM
    Rank: Member

    Joined: 4/24/2006
    Posts: 11
    Location: USA
    rip wrote:
    interesting.

    "" gives that message, "12:14:16" results in "121416" in the output file, but when I don't connect anything at all, I get 14215735.

    hm hm hm. interesting.

    seems to contradict this page (very bottom) as 14215735 isn't ISO 8601 I don't think.

    You should file this with Altova support I think.

    rip


    My SMP already expired :(, seems to renew my SMP for only this issue.
    rip
    Posted: Wednesday, November 4, 2009 12:41:15 PM
    Rank: Advanced Member

    Joined: 7/17/2008
    Posts: 185
    Location: Minutiae, Triviality
    Ok, the current run shows: 14325345

    And my system clock shows 14:32, so I'm assuming that the run was at 14:32:53, but no idea if the auto-complete is supplying decimal seconds, but this violates ISO 8601:

    (en.wikidpedia.org/)

    Decimal fractions may also be added to any of the three time elements. A decimal point, either a comma or a dot (without any preference as stated most recently in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a separator between the time element and its fraction. A fraction may only be added to the lowest order time element in the representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5" or "1430,5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties.

    So there is no decimal, so that at least is incorrect.

    Funnily enough... my original -in-jest- post of "substring(.,1,8)" is probably exactly correct but not settable where you need it. Use a "now()" fed into "time-from-datetime()" fed into "substring()", with constant numbers of 1 and 8 as the start-at and length fields. Feed _that_ into the F337 where this incorrect time is being generated...

    Going through the substring is suggested, since my check of now()->time-from-datetime() is also returning 8 characters, which doesn't seem correct, and it might mean the occasional 9 or 10 character string.

    rip
    Posted: Wednesday, November 4, 2009 12:44:06 PM
    Rank: Advanced Member

    Joined: 7/17/2008
    Posts: 185
    Location: Minutiae, Triviality
    Waqar wrote:
    My SMP already expired :(, seems to renew my SMP for only this issue.


    Can't help you with that. SMP is a good thing.

    But, file it anyway. You'll get back a "thanks for bringing this to our attention" :) but at least it will be on record.
    Waqar
    Posted: Wednesday, November 4, 2009 12:45:23 PM
    Rank: Member

    Joined: 4/24/2006
    Posts: 11
    Location: USA
    rip wrote:
    Ok, the current run shows: 14325345

    And my system clock shows 14:32, so I'm assuming that the run was at 14:32:53, but no idea if the auto-complete is supplying decimal seconds, but this violates ISO 8601:

    (en.wikidpedia.org/)

    Decimal fractions may also be added to any of the three time elements. A decimal point, either a comma or a dot (without any preference as stated most recently in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a separator between the time element and its fraction. A fraction may only be added to the lowest order time element in the representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5" or "1430,5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties.

    So there is no decimal, so that at least is incorrect.

    Funnily enough... my original -in-jest- post of "substring(.,1,8)" is probably exactly correct but not settable where you need it. Use a "now()" fed into "time-from-datetime()" fed into "substring()", with constant numbers of 1 and 8 as the start-at and length fields. Feed _that_ into the F337 where this incorrect time is being generated...

    Going through the substring is suggested, since my check of now()->time-from-datetime() is also returning 8 characters, which doesn't seem correct, and it might mean the occasional 9 or 10 character string.



    You are correct, i once used NOW function but it was also not stable some time 8 character some time 10. I have almost lost half of my hair solving this problem. What a pain in back side.
    Users browsing this topic
    guest

    Forum Jump
    You cannot post new topics in this forum.
    You cannot reply to topics in this forum.
    You cannot delete your posts in this forum.
    You cannot edit your posts in this forum.
    You cannot create polls in this forum.
    You cannot vote in polls in this forum.

    Use of the Altova User Forum(s) is governed by the Altova Terms of Use.