Hi Scott,
No, I didn't code the ASCEND or DESCEND keyword on the DS definition. The
problem was that in the first iteration of the loop, the %Lookup BIF set j
equal to 0 when searching for the date value in the array (yes, we use
numeric dates). This was expected since each array element equaled 0 on
the first iteration. So the code incremented i to 1 and set depDats(i)
equal to the date value. On the second iteration (and second deposit
record), the date value was the same. %Lookup should have then set j equal
to 1, but it instead set it equal to 0. So i was then incremented to 2,
and depDats(i) set to the same date value. The exact same code worked as
expected when depDats was a stand-alone field.
Just to double-check things before responding, I removed the 26A,
recompiled and ran the program in debug. To my surprise, it worked. I put
the 26A back in, recompiled and re-ran. It still worked. As you mentioned,
the 26A is not an issue one way or another, just superfluous. So I
obviously did something wrong somewhere -- maybe I changed the code
without recompiling, I don't know, which is really frustrating. I am glad
it now works, though. Sorry to have wasted your time, but thanks for the
assistance nonetheless.
Blake
hi Blake,
I don't see any reason why this code shouldn't work. Can you explain the
problems you're having? What errors/symptoms do you get?
Can you please verify that your real code (as opposed to the code in the
e-mail) doesn't have the 'ASCEND' or 'DESCEND' keywords on the array? If
it /does/ have these keywords, that would explain why it fails. But since
you aren't using them in the >e-mail post, I don't see why it wouldn't
work.
You might want to eliminate the silly hard-coded '26A' since it's
superfluous -- but it wouldn't cause the program to not work, it's just
silly to hard code something that doesn't need to be hard coded. (RPG can
out the length of dsTots automatically.)
midrange.com
