> By default Jaybird will make a connection with characterset NONE. If you
> want to use a different characterset (and you usually want that!), you
> need to explicitly specify it in the JDBC url (or if you use a
> datasource: in the datasource properties).

Hmmm, it sounds like it is not standard JDBC property ?

If Java apps always run in some pre-defined flavour of unicode, if the database is created in some standard charset (here - UTF8), why cannot JayBird query database and choose best matching default.

Yes, potentially different tables/columns MIGHT have different charsets, but that is marginally rare case and that is when one could override default by JDBC URL options.

I would ask TS to implement that parameter, since they had some built-in language selection. But overall to me it looks a bit outdated approach.

It seems TS developers failed to do it right, and mere users would fail too.

> > And there would be half-dozen things to subclass.
>
> Not sure why you would need to subclass half-dozen things. You would
> only need to subclass the dialect.

Mmm... i meant subclassing here like Windows Ui where u 'subclass' each windows.
I meant like subclassing the Dialect contains (consists of) subclassing those datatypes one by one. And only one type would not be enough.

...and then i wound need to compile it and replace it in the hibernate Jar probably. Frankly, i fear that surgery session :-)

Thanks. Hope to hear from u next week.
Hope it would be both useful for me and for u, if you would find something useful from that TS crash.