Roman,
First off thanks for catching the question within an answer. Sorry about
that.

On Sun, 2003-03-09 at 05:22, Roman Rokytskyy wrote:
> > Is there any benefit to say using setDate as opposed to setString,
> > or setLong instead of setString.
> >
> > Simply is there any benefit to passing the exact data format stored
> > in a column?
> >
> > For some I specify, but for the most part I just use strings, and
> > have not run into any problem so far. At least none that I am aware
> > of.
>
> a) you save some CPU cycles of your client for conversion and garbage
> collection (conversion is performed on the client before sending data
> to the server).

When I am dealing with GUI, most fields and etc. want strings. So when I
set the gui field values, or retrieve them I am dealing with strings.

So I usually extract and insert them as strings. Is this the preferred
method?

I assumed since the conversion would be taking place either way, that I
would simple do it one. Once on retrieval.

During inserts, by the time the SQL is executed values should be in
native formats.

For example

static void insert(String s,String i,String l,string d) {
StringBuffer sq = new StringBuffer();
sq.append("INSERT INTO MY_TABLE (S,I,L,D) VALUES (");
sq.append("'"+s+"',"); // inserting string
sq.append(i+","); // inserting a integer
sq.append(l+","); // inserting a long
sq.append(d); // inserting a double
Statement statement = connection.createStatement();
boolean b = statement.execute(sq);
statement.close();
}

A crude example but by the time the sql makes it to Firebird, the
numeric values are numeric. They are no longer strings. Correct?

For me I rarely use the PreparedStatement.set*();

The only time I tend to use that is with blobs. Then I will do a
PreparedStatement.setBytes();

Although I believe I could get away with using setString() instead of
setBytes.

I basically do updates the same way as inserts. I tend to pass all
values as strings, and use '' in the sql to tell Firebird which ones
should really be treated as strings.

Now of course when dealing with extracted data I mostly use
ResultSet.getString(); since most of the time I am setting a GUI field
via

JTextField.setText(ResultSet.getString("COLUMN"));


> b) you might run into troubles when we will not be able to parse your
> string.

Could you explain or provide an example of something that might cause
trouble. I have not run into any problems so far, but that does not mean
I am not sitting on a time bomb.

Of course outside of the obvious, like inserting a funky date as a
string into a date field. I know if I do pass Firebird a date string
that it can recognize then it will handle the conversion. If it pass a
funky one Firebird will puke.

--
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax 707.766.8989
http://www.obsidian-studios.com
--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax 707.766.8989
http://www.obsidian-studios.com