Hi, I have two alternative suggestions.
1. Test your code. Simple test cases will ferret out these problems before they hit a production environment. 2. Peer review. Let someone else look at your code before you migrate it to a production environment. This, in my experience, is an effective way of finding logic errors in code. Please don't take these suggestions as sarcasm. Relying on your tools to catch anything other than syntax errors is a bad idea. It builds in a false sense of security. John Griffin -----Original Message----- From: Dave Dyer [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 4:24 PM To: [EMAIL PROTECTED] Subject: fail-safe queries I'm a little concerned by the possibilty of a malformed query accidentally destroying a whole databse. For example, a badly constructed boolean, intended to select exactly one row, but which actually modifies all rows. update mytables set data='who' where row='1234'; (updates 1 row) verses update mytables set data='who where row=1234'; (damages all rows) The obvious answer is to use a LIMIT clause to limit the damage, but (1) there is still damagage (2) the LIMIT clause is as likely to be damaged as the WHERE. update mytables set data='who where row=1234' LIMIT 1; (damages 1 row, gives no indication of error. Better I suppose.) So my proposal is a "FAIL IF rows>1" type clause, which would be syntactically FIRST in the string, and so unlikely to be damaged by errors constructing a complex query. FAIL IF rows>1 update mytables set data='who where row=1234'; (fails, damaging no rows.) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
