Which is where you put into the decision 'black box' of your program a check to see how many rows were modified. If something was supposed to be changed, but zero rows were updated, throw an alert. If one or a reasonable amount were changed, don't inform the user. If more than a reasonable amount of rows were changed, inform the user that there could have been a problem. Albeit, you're correct if you're going to be alerting the user to TOO many rows changing, you MIGHT want to open a transaction, count the affected rows, then confirm the change......
In an N-Tiered application, (Data, Business, and User Interface being the basics) the database did its job successfully. Updated all rows you required to be changed. Because it was zero rows means nothing to that tier (The data tier) of your application. However, to the business logic MIGHT care that zero rows were affected, which in this case, the UI might need to be told about it. On Fri, Feb 22, 2013 at 6:06 PM, Frederick Wasti <[email protected]> wrote: > Thanks for your replies. What you have all said makes sense (and, in my > defense, I did suggest that a nonsense - but properly formed - SQL > statement could still be processed "OK"). :-) > > I first noticed this situation when studying the sample code for the > "SmartDB" C++ wrapper for SQLite. The author's code uses the return value > from sqlite3_exec() to report to the user whether the SQL entered by the > user succeeded or not. Having a msgbox report to the user that the "Query > was executed successfully" is actually, from a software ~user's~ point of > view, rather misleading. > > From a ~user's~ point of view, I think that if the code tested for the > possibility of ~not~ actually being able to modify a DB with an attempted > UPDATE query (perhaps by internally using a SELECT statement first, just to > see if the UPDATE's WHERE condition would even be feasible) might be a good > strategy. [The ~user~ might just like to be informed that the ~expected~ DB > write did ~not~ occur, even if the SQL looked superficially OK (and indeed > was properly processed by sqlite3_exec() "OK", too).] > > Thanks. > > Fred > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
