Subject Re: [Firebird-Java] Re: Error 504: Problem with Win2000 and driver 1.5.4
Author Roman Rokytskyy
> I /knew/ I should have included a stacktrace, stupid me... the Win2k
> box is a work colleagues, but I may be able to pop back into the
> office before next week and get a trace.

Ok, then I wait for stack trace. It contains more information that is
available to me.

> Yes, every time with the same query, and with some others also...

Ok, then this is already something. I have Win2k box at home, so I can test.
BTW, what version of Firebird do you use?

> Because I don't know what it is about that particular query that
> causes the problem, I don't know how easy it will be to create a
> simple stand-alone test case.

First try the exact that query (you have to create all tables, probably with
some test data).

> One thing that may be a factor - it is possible that the person who
> wrote that bit of code may have requested updateable and/or
> bi-directional scrollable cursor when creating the statement. Could
> that be the problem? I warned them not to because I think some docs
> said some of those features were unsupported, but some of it /did/
> work with the 1.5.0beta3 driver (and I assumed that would be
> temporary!).

No, I doubt. At least you do not use anything unexpected in that code you
posted. Please post a stack trace.

> One other interesting thing I noticed when changing from the
> 1.5.0beta3 driver to 1.5.4: I run a large migration program and with
> the new driver it complained about a char column truncation (the old
> driver didn't). That's a good thing because I wasn't aware of the
> problem in the data which I've now fixed... was the 1.5.0beta3
> driver allowing some column truncation to pass silently?

As far as I remember, previous version simply relied on Firebird to report
data truncation, but in some cases it led to server crash. So we have
decided to report it before. Most likely in your case you (VAR)CHAR columns
were multibyte (for example UNICODE_FSS), and you stored characters from the
0-255 range. They would fit the column bytewise because server reserved 3-x
bytes per char in case of UNICODE_FSS. Our code checks character size, not
the byte size.