> > Lines below Hibernate Dialect seems to be default ones, ichanged pools to 1/1 with no difference.
> > hbm.xml files are customized for some servers, but it seems that no SQL is sent to server at all. I cannot look at it on Jaybird/FB level, but i could see HSQLDB statements after tweaking logback.xml
>
> Jaybird logs statements using Log4J (if it is on the classpath), if you
> have configured it to log trace level.

XWiki does not use Log4J.
It uses LogBack with SLF4J API and Log4J-to-SLF4J bridge

I did not saw any JB logs in places i can saw other logs.

However, this problem is hardly be JB-related.
Hibernate tries and fails to create SQL script for DB init, hence i think JB is not called to run it and hardly JB/FB wouldbe called to determine present features of actual FB installation - that would seemingly be to much to expect from Hibernate FBDialect and wrong strategy backup-wise.

Afterall, maybe more productive approach to get those log would be to use JamonAPI wrapper over JB, but it is not on the list yet :-)

When SQL errors would be - yes. But to get there one needs that SQL generated :-)

I wish Hibernate would not jsut bail out, but log somewhere which parts of script it already generated and which class he failed to generate next part of script for.

> Type -1 is java.sql.Types.LONGVARCHAR, which is the type identification
> which Jaybird uses for BLOB SUB_TYPE 1. The FirebirdDialect in Hibernate
> does not have that type mapping (instead it maps java.sql.Types.CLOB to
> BLOB SUB_TYPE 1).

> The quickest solution will probably be to extend FirebirdDialect and add
> the following to the constructor:
>
> registerColumnType( Types.LONGVARCHAR, "blob sub_type 1" );

Do you know there was some person subclassing FB dialect for JIRA ?
his main problem was long names exceeding 32 length though.
If you really would do, i guess his work or at least his problms are to be targeted too. Maybe even some explicit table for names redirection instead heurystical name shrinking in hope that they would have little chance to clash. And probably using FB descriptions to store full names.

I wonder if it is feasible/worth candles to extend Hibernate, so it would store into DB Scheme which program classes/properties are represented by given scheme element. FB description might be good thing to re-use. However it seems that Hib3 archetecture would not allow keeping such hints...

> I do have plans to write a better dialect for Hibernate, but I currently
> simply don't have the time (I do hope to get more time for releasing
> Jaybird 2.2 and other things in the coming month).

Oookay...

TrackerStudio guys are aiming at .17 release. So they are not about Firebird right now.
FB for them is unknown and unloved child asked by some strange clients.
Up to the point that their support guy told me that FB only supports KOI8-R charset (you would hardly get the irony, but that is the charset that used in russian for UNIX/PDP-11/such, while IB after Borland's aquicition was mainly targeted for Windows where KOI8-R is used almost never)

But if u really gonna have look at them, then (as of TrackStudio 4.0.16 Win standalone (Jetty/win + preinstalled TS WAR), russian database template, FB 2.5.1)
1) their built-in DB creation non-functional; I suspect they do double 1251->UTF8 conversion, inflating data beyond 2KB column sizes.
2) they have SQL script for DB creation, encoded in Win-default russan charset "windows-1251"
3) that script might be run via FlameRobin to correctly init UTF8 database
3.1) but not via IBExpert
3.2) but database would still be unsuable due to charset issues

I did not checked English template DB creation. It probably would work. Dunno.

The TS4016-SA installation carries JB216 in WAR\lib, and i think TS4016-WAR does too
However if both JB216 in WAR lib and JB220b1 in JRE (i used win64 7-b05 JRE on Win7 x64) ar present then NONE of db connections inside TS can be used. Something wrong with pool creation or such.

However, even if there is bug in JB220b1 (which is not obvious from that, maybe app could confused use half the 216 jar and half the 220b1 jar to unpredictable results ?) such an global disabling is i think bug on TS/Spring/JDBC side. However awfully bad JayBird might be, i think it SHOULD NOT affect pure-HSQLDB connectivity. And if it did - something is wrong in modularity in the app/libs themselves.

It would be very nice if you include TrackStudio into Jaybird test suite, yet it is not hi priority i think for 2.20 release