Conference iosg::all-in-1_v30

Hi,

A brief answer to your main question:

>> Is there a way to convert the data type back to "INTEGER"

An "integer" that a user enters in a field is never stored by ALL-IN-1 as an
integer: the user enters a string of ASCII digits, and that is exactly what
ALL-IN-1 stores.  In V3.0 you can probably (with a bit of contortion!) use the
FN$ string functions to make (eg) a binary longword from such a string, but
that doesn't help your V2.4 user, and also see the comments below about control
characters in ALL-IN-1 strings.


Now some questions to clarify exactly what's going on:

When you say the key of the second file is an INTEGER, do you mean that it is
(eg) a binary longword (rather than a string of ASCII digits?)

When you say the user enters an INTEGER into a field, I presume you mean they
type in ASCII digits?

This field of ASCII digits is then used as key to the first file, yes?

Another field(s) of the first file contains (eg) a binary longword, yes?

This (eg) binary longword is used as key to the second file, yes?


If all the above are true, then is this the right flow of logic, and does it
work (substituting suitable names and values, of course!):

GET #DIGITS = "123456"
GET #BINARY = FIRST_FILE.BINARY_FIELD[#DIGITS]
GET #RESULT = SECOND_FILE.RESULT_FIELD[#BINARY]

Assuming that's the right flow of logic for your problem, then I don't think it
will work, because ALL-IN-1 symbol processing assumes that symbols contain ASCII
data, and other values may get truncated (see a note of mine earlier in this
conference about storing ASCII control characters in ALL-IN-1 symbols).

So sorry, no magic solution, but if you can confirm (or correct!) my
description of what the customer is doing, then at least we'll know where to
look for an answer.

Scott

    
    	See the /CONVERT_DATA feature in ALL-IN-1 V3.0 (API ref Vol 1).
    	Not available on V2.4, sorry.
    
    Regards,
    Paul

Scott,

Generaly you have got it right. I have made some mistakes in my description of
the flow, so I'll correct them now.

>Now some questions to clarify exactly what's going on:
>
>When you say the key of the second file is an INTEGER, do you mean that it is
>(eg) a binary longword (rather than a string of ASCII digits?)

Yes.

>
>When you say the user enters an INTEGER into a field, I presume you mean they
>type in ASCII digits?

Well, the user doesn't enter an INTEGER into the field. He enters a value
(string) to the field. That string is the key of the first file. Another field
in that file is binary and that field is the key for the secondary file. The
lookup in the second file fails because when ALL-IN-1 stores the value of
the other field in a symbol it is converted to ASCII string.

>This field of ASCII digits is then used as key to the first file, yes?

No, as explained here. The only change is that it is a field of ASCII string
rother then a field of ASCII digits.

>Another field(s) of the first file contains (eg) a binary longword, yes?

Yes.

>This (eg) binary longword is used as key to the second file, yes?

Yes.

>If all the above are true, then is this the right flow of logic, and does it
>work (substituting suitable names and values, of course!):
>
>GET #DIGITS = "123456"
>GET #BINARY = FIRST_FILE.BINARY_FIELD[#DIGITS]
>GET #RESULT = SECOND_FILE.RESULT_FIELD[#BINARY]

Just change the "123456". But that won't change the general flow.

rep 2:

the /CONVERT_DATA is 3.0 fetaure, so it won't help here. Anyhow, I'm not sure
it will help anyway. It is stated in the documentation that you cannot do keyed
lookups if the key contains a field qualified by /CONVERT_DATA. In fact, it
looks like the use of /CONVERT_DATA in the direction of "FROM ALL-IN-1 SYMBOL
TO A FIELD IN THE FILE" is for write functions and not read functions.

Thanks for help,
Yariv

Hi,

This is confusing:

>> when ALL-IN-1 stores the value of
>> the other field in a symbol it is converted to ASCII string

I wouldn't expect ALL-IN-1 to do this.  If it's an ordinary entry form mapping
an ordinary RMS file, then ALL-IN-1 will just fetch the field "as is" (ie a
string of 'n' bytes).  This may give problems with binary data, as explained
earlier, but ALL-IN-1 won't automatically do any conversion.

Either I'm missing something, or there's something else going on here...?

Scott

Hi,

>> it has problems looking for the binary value at
>> the second file, just like explained before

This is because ALL-IN-1 symbol processing assumes that everything is
printable ASCII characters: non-printable characters (which you will get when
reading binary data!) can get stripped from the front/end of symbols.  Note
that binary data embedded in a string of printable characters is OK.

(Aside: I can guess why this is happening, but don't see any reason why it has
to be like this: so is it a bug?)

I wrote a note in here some time back giving suggestions for how to get round
the problem.  That note was to do with VT escape sequences, so I don't know
whether it will help you.  Sorry, don't have time to look up the note number.

Scott

� (Aside: I can guess why this is happening, but don't see any reason why it has
� to be like this: so is it a bug?)
    
    I imagine it's a feeble attempt at a short-cut to strip "white space"
    from the front of the string - i.e. <space> <tab> <lf> <cr> <HT> <FF>.
    I'd guess that whoever coded it thought it easier to discard all
    control characters instead of just checking for these.
    
    Of course, even if the code were changed so it only discarded the above
    characters, it would still potentially screw up "binary" data.
    
    D.

re .8, yes that's what I thought.

Hmm, not really a bug I suppose, but certainly a "feature".

How about a ":B" symbol suffix, to denote binary data and prevent trimming?
(cf :H for Hebrew)

Scott