Subject | Re: SQL Query -> DataTruncation Exception |
---|---|
Author | rwilcom |
Post date | 2004-11-03T14:18:14Z |
I tend to side with Gabriel on this one - especially when it comes
to a "VarChar". Why not just make the "VarChar" as big as any
allowable search (including the wild cards)? You won't be using up
any more space in the database since for values held within that
column since a "VarChar" column only allocates what it needs
(right?).
Ron
to a "VarChar". Why not just make the "VarChar" as big as any
allowable search (including the wild cards)? You won't be using up
any more space in the database since for values held within that
column since a "VarChar" column only allocates what it needs
(right?).
Ron
--- In Firebird-Java@yahoogroups.com, Gabriel Reid <gre@a...> wrote:
> On Wed, Nov 03, 2004 at 02:16:15PM +0100, Roman Rokytskyy wrote:
> >
> > > When pass in a parameter, the "?" of a length higher than 10,
say "%
> > > searchphrase" the query fails with a data truncation exception
from
> > > Jaybird.
> >
> > JayBird cannot distinguish between params that are used in LIKE
and those
> > used in assignment. However, when you pass long enough param in
assignment,
> > it leads to server crash (bug in Firebird). At some point (and
after
> > discussion in this group) it was decided to throw that exception
when the
> > passed search string is bigger then the declared length of the
field. This
> > happens only for parameters and has no influence if the search
pattern is
> > included in the SQL statement.
> >
> > Apparently it can be considered a bug for your case. Please fill
a bug
> > report, so the issue is not lost.
> >
> > The only solution for this issue is to fix the bug in Firebird,
then we can
> > remove the limit in JayBird. At present the only workaround I
can suggest is
> > to extend the size of the column to be big enough for all LIKE
searches.
>
> I would like to make a case for _not_ considering this a bug. I
feel that it
> is only logical that binding an oversized value to a fixed-size
field should
> throw an exception, regardless whether or not the bind parameter
is being
> used as an update value, a value comparison, or a filter
parameter. There is
> no use (that I can think of) for binding an oversized parameter in
a search
> filter; thus I feel it is more reasonable to consider this to be a
programmer
> error than a bug in the driver. Finally, this behaviour (not
accepting an
> oversized bind value for a filter parameter) is consistent with
the behaviour
> of both the kinterbasdb driver for Python, and the DBD::InterBase
driver for
> Perl.
>
> Gabriel