> But if I switch to and use execute instead of executeUpdate, I will
> then need to call getUpdateCount myself no?
>
> How else can I determine if the update/insert/delete was successful
> or not?

Well... That's probably not a JDBC issue. I would say, if you have
normalized database with integrity constraints, you should not care
about how many rows were inserted/updated/deleted. That is
statistics, not consistency check. Your transaction will either
succeed or fail. However, what is better - integrity constraints on
the server or update count on the client?

I think that Java people tend to forget what is relational database
and use them in very simple manner. I do remember times when I was
programming in Delphi and I had no problems moving most of my code
into stored procedures, but now I tend to think "SP, oh no, if I
switch to another database I have to re-implement them... better no"
and first try to implement same thing using SELECT, INSERT, UPDATE
and DELETE statements. Is it good? I doubt...

Roman