Re: Nameless CREATE

On 20 Dec, 13:59, Alex McDonald <b...@xxxxxxxxxxx> wrote:
On Dec 20, 1:51 pm, douglasr <douglas.r...@xxxxxxxxxxxxxx> wrote:

On retrieving the data via ODBC functions into the Forth programme
I observe the following:

BinaryColumn DUMP
1C988A 54 00 65 00 78 00 74 00 20 00 69 00 6E 00 20 00
T.e.x.t. .i.n. .

So, every second character is a 00

It's actually Unicode. There are Windows functions MultiByteToWideChar
and WideCharToMultiByte that can translate between ASCII and Unicode;
ther may even be some flag that you can set hen talking to ODBC that
does the translation for you (I've not checked).

--
Regards
Alex McDonald- Hide quoted text -

- Show quoted text -

I shall be surprised if the problem relates to Unicode.

I have no problem with character and MEMO fields even although Access
itself
optionally stores these as Unicode.
In the column definition I can specify whether I want the underlying
Jet database to store characters as a single byte
(Compressed in the Access terminology)
or as double bytes to support Unicode.
I tried both and for either variant retrieve into ODBC as single bytes
since,
by default, it seems that ODBC maps characters to single bytes.
So I didn't have to do anything in ODBC whether or not the database
itself stores as a single or double byte.

Since BINARY and IMAGE fields relate to binary data rather
than characters, one would assume that the subject of Unicode
which relates to character encoding would have little or no relevance.

There is nothing in the Access user interface that enables an image
field
to be specified as a particular data format whereas, for a MEMO
field,
one can toggle between Unicode and non-Unicode alternatives.

It did cross my mind that perhaps this could be the issue
and I tried to define a COMPRESSED BINARY
or a COMPRESSED IMAGE field using the keywords
WITH COMPRESSION in the DDL SQL statement.
However, these words are rejected by the database
for other than character or MEMO field definitions.

I have studied the ODBC documentation fairly closely
and have not read of any options relating to this for binary data.
The default conversion is to SQL_C_BINARY and no alternatives are
described at least in relation to binary data.
I am unable to find a formal definition of exactly what SQL_C_BINARY
is.

For characters there are types like SQL_C_CHAR and SQL-C_WCHAR
but the W variant (presumably W for wide) is certainly not the
default.

Douglas
.

Relevant Pages

  • Re: how to communicate unsigned char* to Java
    ... occure within the binary data which are no valid Unicode. ... every possible value has an opposite Character within ANSI ... As opposite to Unicode: ... 00 The sequence is illegal. ...
    (microsoft.public.win32.programmer.networks)
  • Re: how to communicate unsigned char* to Java
    ... occure within the binary data which are no valid Unicode. ... every possible value has an opposite Character within ANSI ... As opposite to Unicode: ... 00 The sequence is illegal. ...
    (microsoft.public.win32.programmer.networks)
  • Re: how to communicate unsigned char* to Java
    ... occure within the binary data which are no valid Unicode. ... every possible value has an opposite Character within ANSI ... As opposite to Unicode: ... 00 The sequence is illegal. ...
    (microsoft.public.win32.programmer.networks)
  • Re: VB - Ascii to Unicode and then Unicode to UTF-8 conversion (Very desperate!!)
    ... Latin together) then you have to use a Unicode column type. ... AscW returns the real Unicode character ... for Chinese characters, ... then the next thing to worry about is your CSV file. ...
    (microsoft.public.vb.general.discussion)
  • Re: Unicode Support
    ... if two Unicode strings are the same? ... UTF-16 is basically telling everyone "ok we all got to start ... character, and will likely support *both* endians. ... UTF-8 encodings are also easy to learn to ...
    (alt.lang.asm)
Loading