Win a copy of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications this week in the Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Getting a DB2 SQL Code when there is no SQLException  RSS feed

 
Donna Reschke
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am executing an update that is successful but may or may not be updating a row based on the WHERE clause. How can I retrieve the SQL code and determine whether or not a row was updated?
Thanks, Donna
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, you can't. Most drivers, support returning an integer value as the output of the result set indicating the number of rows updated or inserted but I believe there is some notion that this is not 100% guarenteed.

If you are performing the update/insert and want to stop if something fails, wrap the entire group of updates/inserts as part of a transaction that can later be rolled back.
 
Tim LeMaster
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, you can't.


This is news to me. executeUpdate() returns an int. In the case of an INSERT/UPDATE/DELETE it should return the number of rows effected. In case of an SQL statement that doesn't return a value it returns 0. Of course it can return a 0 on INSERT/UPDATE/DELETE if no rows are effected.

If there are cases where this doesn't work I would think they are far in the minority.

Since you mention DB2 specifically I know this works with DB2. (and Oracle and SQL Server and mySQL)
[ October 23, 2006: Message edited by: Tim LeMaster ]
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry Tim, what I should have said is that behavior like this is not supported by 100% of JDBC drivers, therefore you face portability issues if you rely on it. I was under the impression there were cases that this broke such as if too many records were updated or if triggers/stored procedures were involed.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!