Re: What exactly is a "Binary Character" field?

On 16-Jun-2015 16:47 -0600, James H. H. Lampert wrote:

<<SNIP>>

I set up a test file:

A R FOO
A BAR 85
A BAZ 8A
A QUX 8H

It's the same one I mentioned earlier, except that (because Chuck
brought up Hex fields) I added a Hex field to it.

Now, I can't figure out any way to get data into the test file via
an SQL INSERT statement: it rejects anything I put in, giving
various "invalid data" messages about what I try to stick into BAR.

I am unsure if the restrictions were eased with newer releases, although I seem to recall they were, but the mapping into and out of BINARY are quite draconian; in older releases, not even using Hex notation is recognized as compatible. The following casting expression will allow the character string to be placed into the BINARY field named BAR using the INSERT with VALUES:

INSERT INTO test_file (BAR) VALUES( CAST('08 Bytes' as BINARY) )

But I CAN put data in with QuestView. And if I switch QV to Hex mode,
I can even put it in as hex.

If I do that, STRSQL will display all 3 fields as character.

But Squirrel SQL displays BAR as a string of discrete hex byte
values, with lowercase for digits a-f, separated by spaces, but it
displays QUX as a string of undelimited hex digits, with uppercase
for digits A-F.

This just keeps getting weirder.

What a report writer chooses to display for the various /binary/ character string types is by their choice. The Query/400 report writer used by the Start [Interactive] SQL (STRSQL) feature made [what IMO is] the unfortunate choice of showing H=Hex data type as character data rather than as a form of a hexadecimal string notation; for minimal change, the same effect is seen for the BINARY data type. Both are consistent with Alpha CCSID(65535) which is synonymous with CHAR FOR BIT DATA, but I do wish I had been more emphatic in my suggestion back in V1R1 that Query/400 should be presenting H=Hex in hex notation :-( With the HEX scalar, at least one form is available; that was one of a few argument against the Query/400 report writer implicitly presenting hex notation, despite there being no X2C scalar.