SQL Statement Categories Issuing Queries and Retrieving Results

processing a bit and I dont want t o deal wit h t hose com plicat ions unt il we get t o Recipe 2.8 and Recipe 2.9 .

2.5.4 SQL Statement Categories

SQL st at em ent s can be divided int o t wo broad cat egories: • St at em ent s t hat do not ret urn a result set t hat is, a set of rows . This st at em ent cat egory includes INSERT , DELETE , and UPDATE . As a general rule, st at em ent s of t his t ype generally change t he dat abase in som e way. There are som e except ions, such as USE db_name , which changes t he current default dat abase for your session wit hout m aking any changes t o t he dat abase it self. • St at em ent s t hat ret urn a result set , such as SELECT , SHOW , EXPLAIN , and DESCRIBE . I refer t o such st at em ent s generically as SELECT st at em ent s, but you should underst and t hat cat egory t o include any st at em ent t hat ret urns rows. The first st ep in processing a query is t o send it t o t he MySQL server for execut ion. Som e API s Perl and Java, for exam ple recognize a dist inct ion bet ween t he t wo cat egories of st at em ent s and pr ovide separat e calls for execut ing t hem . Ot hers such as PHP and Pyt hon do not and have a single call for issuing all st at em ent s. However, one t hing all API s have in com m on is t hat you dont use any special charact er t o indicat e t he end of t he query. No t erm inat or is necessary because t he end of t he query st ring im plicit ly t erm inat es t he query. This differs from t he way you issue queries in t he m ysql program , where you t erm inat e st at em ent s using a sem icolon ; or \g . I t also differs from t he way I norm ally show t he synt ax for SQL st at em ent s, because I include sem icolons t o m ake it clear where st at em ent s end. Aft er sending t he query t o t he server, t he next st ep is t o check whet her or not it execut ed successfully. Do not neglect t his st ep. Youll regret it if you do. I f a query fails and you proceed on t he basis t hat it succeeded, your program wont work. I f t he query did execut e, your next st ep depends on t he t ype of query you issued. I f it s one t hat ret urns no result set , t heres not hing else t o do unless you want t o check how m any rows were affect ed by t he query . I f t he query does ret urn a result set , you can fet ch it s rows, t hen close t he result set . Dont Shoot Yourself in the Foot: Check for Errors Apparent ly, t he principle t hat you should check for errors is not so obvious or widely appreciat ed as one m ight hope. Many m essages post ed on MySQL- relat ed m ailing list s are request s for help wit h program s t hat fail for reasons unknown t o t he people t hat wrot e t hem . I n a surprising num ber of cases, t he reason t hese developers are m yst ified by t heir program s is t hat t hey put in no error checking, and t hus gave t hem selves no way t o know t hat t here was a problem or t o find out what it was You cannot help yourself t his way. Plan for failure by checking for errors so t hat you can t ake appropriat e act ion if t hey occur. Now were ready t o see how t o issue queries in each API . Not e t hat alt hough t he script s check for errors as necessary, for brevit y t hey j ust print a generic m essage t hat an error occurred. You can display m ore specific error m essages using t he t echniques illust rat ed in Recipe 2.3 .

2.5.5 Perl