On Sun, 10 Nov 2002, Henri Yandell wrote:
> Going over Ken Fitzpatrick's suggested new methods: > > +++++++++++++++++++++++++++++++++++++++++++++++ > SQL > === > > getSqlEscapedColumnValue( String s ) : String /** Returns an SQL-based > escaped > equivalent of s (ex: map "Bob's" to "Bob''s", etc.) */ > > +++++++++++++++++++++++++++++++++++++++++++++++ > > getSqlWhereEqualsColumnValueOrIsNull( String s ) : String /** Returns "= > '[s]'" > (if s != null) or "is null" (if s == null) for safely building SQL Where > Clause > Predicates like "ColumnName = 'Bob'" or "ColumnName is null" */ > > +++++++++++++++++++++++++++++++++++++++++++++++ > > getSqlColumnValueOrNull( String s ) : String /** Returns s or the String > "null" > such that the returned value can be used to safely build an SQL Update.Set > Clause, Insert.Values Clause, etc. as "Set Col=[s]" where s is the value > returned from this method ... Overloads for Date, Integer, ... */ > Looking at these, it seems that the first and third are easier done by using a PreparedStatement, which knows more about exactly how the particular database likes to escape a ' etc. Is there a big need to provide a String method here, or should people just be upgrading to the PreparedStatement? Hen -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
