Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Getting a DB2 SQL Code when there is no SQLException

 
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
Saloon Keeper
Posts: 4033
18
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
Saloon Keeper
Posts: 4033
18
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