methods where String and int share a parameter value
Hi all,
I have a method for updating an MSAccess table using SQL as follows:
publicvoid fieldUpdate (String table, String field, String username, [b]Object value[/b])
{
try
{
Statement stmt = conn.createStatement ();
String sql ="UPDATE " + table +" SET " + field +" = '" + value +"' WHERE ( USERNAME = '" + username +"' )";
// String sql = "UPDATE table SET field = value [, column_name = value ...] [WHERE condition]
stmt.executeUpdate (sql);
}
catch (SQLException sqle)
{
System.out.println ("couldn't write " + sqle.toString ());
}
}
Everything works as it should, the problem is just theObject up there...
I'm calling the method as follows:
fieldUpdate ("USER_INFO","INT_X", username, x_value);//NOT WORKING
and:
fieldUpdate ("USER_INFO","IMG_PATH", username, img_path2);//img_path2 is a String (WORKING)
I need to be able to use both int AND String as a variable identifiers!!! String works fine because it is an Object, so I guess my question is: How do I make an int an Object? For example into an Integer?
Message was edited by:
Hagen
[1847 byte] By [
Hagena] at [2007-11-27 11:20:33]
First, use PreparedStatements.
PreparedStatement ps = con.prepareStatement = "UPDATE " + table + " SET " + field + " = ? WHERE USERNAME = ? ";
ps.setString(1, value); // assuming the value was a string
ps.setString(2, userName);
ps.executeUpdate();
As for the different types, several choices spring to mind.
* A different method signature for each type.
* An additional parameter that specifies the type.
* java.sql.DatabaseMetatData that tells you what type the given column is.
* Just using PreparedStatement.setObject() might work--let the driver figure it out--but I've never tried it. Autoboxing may take care of the int-->Integer conversion for you. If not, you'll have to wrap your int in an Integer yourself.
jverda at 2007-7-29 14:43:22 >
> First, use PreparedStatements.
> PreparedStatement ps = con.prepareStatement =
> "UPDATE " + table + " SET " + field + " = ? WHERE
> USERNAME = ? ";
> ps.setString(1, value); // assuming the value was a
> string
> ps.setString(2, userName);
> ps.executeUpdate();
>
>
> As for the different types, several choices spring to
> mind.
>
> * A different method signature for each type.
>
> * An additional parameter that specifies the type.
>
> * java.sql.DatabaseMetatData that tells you what type
> the given column is.
>
> * Just using PreparedStatement.setObject() might
> work--let the driver figure it out--but I've never
> tried it. Autoboxing may take care of the
> int-->Integer conversion for you. If not, you'll have
> to wrap your int in an Integer yourself.
Thanks for the reply! I've never really used PreparedStatements (nor heard of them actually) before but they look kinda neat; SQL code can get messy sometimes...
I'm right at the end of my project now so I dont really want to start something new (laziness) I was actually just hoping that there was some kinda of built in function that I didn't know about that would've let me just cast it or something, but I guess I'll just code two different methods then --I was trying to avoid this because it just seems very innefficient.
Thanks for the help
Hagena at 2007-7-29 14:43:22 >
> Thanks for the reply! I've never really used
> PreparedStatements (nor heard of them actually)
> before but they look kinda neat; SQL code can get
> messy sometimes...
Yeah, you almost always want to use PS over plain old Statement. It keeps your SQL cleaner, keeps you from having to worry about escaping things in strings or formatting date/time strings, prevnts SQL injection, and can improve perormance.
> I'm right at the end of my project now so I dont
> really want to start something new (laziness) I was
> actually just hoping that there was some kinda of
> built in function that I didn't know about that
> would've let me just cast it or something,
Like I said, PS.setObject might do that.
> but I
> guess I'll just code two different methods then --I
> was trying to avoid this because it just seems very
> innefficient.
How would having two methods be inefficient?
jverda at 2007-7-29 14:43:22 >
