🚀 go-pugleaf

Hi!

I need to store some binary data in a MS Access database field.

The obvious way is to open the right row in a recordset and update
the field programatically, but the JDBC-ODBC bridge does not support
updateable recordsets.

The next idea was to prepare an UPDATE statement (PreparedStatement) and
set the data field using setBytes. This didn't work because no matter how
benign binary data I give, MS Access returns me an SQLException saying:

[Microsoft][ODBC Microsoft Access 97 Driver]Invalid precision value

whenever I call setBytes on a PreparedStatement. This worked well with 
MS SQL Server, but Access is an entirely different story.

The next thing was to try to use setString on the PreparedStatement with
the String containing my binary data but...

JDK 1.2.1 Strings are bloody $&#% clever and ALWAYS do some stupid
conversions. I tried to avoid these conversions in many ways but none
worked well because when ByteToCharConverters see a character that is 
undefined for the encoding, it converts it into a '?'. Everybody is
used to seing boxes in place of undefined characters, so I can't see
who would find these '?'s useful.

Here are some methods I tried:

- I tried all SingleByte converters. None do well for me
- I preencoded the byte array into a UTF-8 sequence that would result
  in a correct sequence of chars. However, I again got '?' in places 
  of 127, 128, 129...
- I wrote a ByteToChar converter that would do the trick, but I
  couldn't make String to use it. In vain I even altered the
  font.properties file to use my converter, but it didn't work (I'm not
  surprised about that one - I tried it in vain).
- I tried many other things, which I don't mention because they were not
  supposed to work anyway when I look back.

Ideas like "base64 encode the data and store it" and such won't work for me
because the data must be compatible with legacy programs that use it.

Altogeher, the closest result was using the default (CP1252) converter, 
because it was good for all but 6-7 values above 128. All other converters
ruined more values.

Thanks for any help.

-- 
Kresimir Tonkovic
kresho@ieee.org