> Thanks Vlad, but tell me:
> 1. What are the implications of connecting to a DB with CHARSET ASCII when
> it was created with Charset NONE?

Engine will be able to convert ASCII characters into UTF8 when populated
monitoring tables. It is impossible to convert NONE into the any other encoding.

> 2. This tracker issue doesn't mention invalid Blob ID. The failure
> mentioned... how does it present itself if it is not invalid BLOB ID?

IIRC, some people have "invalid blob id" error before this was fixed.

> 3. I have tested now by changing the application to connect with charset
> ASCII and the monitor application also uses ACSCII, there is now no
> exception raised.

Good

> But I have no knowledge of whether non ascii characters
> are ever placed in the MON$tables. The user name.... all security DBs have
> UNICODE_FSS as the username charset and these values are indeed going into
> the MON$ tables, I have no control over that. What are the implications of
> connecting via charset ASCII and having UNICODE_FSS characters going into
> MON$ tables? Will this cause MON$ table read failures?

I have no full details about this case. Probably Adriano or Dmitry know more.

AFAIU, issue not with data stored in database (such as user names, etc) but with data
supplied by user at run-time such as queries text's, connection string, etc.

Note, ASCII characters have the same representation in the UTF8. So i guess when
string in NONE encoding interpreted as UTF8 string it will fail only if it contain non-ASCII
characters.

Regads,
Vlad