Subject | Re: [Firebird-Java] Re: Error 504: Problem with Win2000 and driver 1.5.4 |
---|---|
Author | Roman Rokytskyy |
Post date | 2004-10-29T13:35:27Z |
> I /knew/ I should have included a stacktrace, stupid me... the Win2kOk, then I wait for stack trace. It contains more information that is
> box is a work colleagues, but I may be able to pop back into the
> office before next week and get a trace.
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 thatFirst try the exact that query (you have to create all tables, probably with
> causes the problem, I don't know how easy it will be to create a
> simple stand-alone test case.
some test data).
> One thing that may be a factor - it is possible that the person whoNo, I doubt. At least you do not use anything unexpected in that code you
> 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!).
posted. Please post a stack trace.
> One other interesting thing I noticed when changing from theAs far as I remember, previous version simply relied on Firebird to report
> 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?
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.
Roman