Đang chuẩn bị liên kết để tải về tài liệu:
Oracle PL/SQL Language Pocket Reference- P7

Không đóng trình duyệt đến khi xuất hiện nút TẢI XUỐNG Tải xuống

Oracle PL/SQL Language Pocket Reference- P7: This pocket guide features quick-reference information to help you use Oracle's PL/SQL language. It includes coverage of PL/SQL features in the newest version of Oracle, Oracle8i. It is a companion to Steven Feuerstein and Bill Pribyl's bestselling Oracle PL/SQL Programming. Updated for Oracle8, that large volume (nearly 1,000 pages) fills a huge gap in the Oracle market, providing developers with a single, comprehensive guide to building applications with PL/SQL and building them the right way. . | as a whole. 6.3.2.2 Vulnerability to data errors If an implicit SELECT statement returns more than one row it raises the TOO_MANY_ROWS exception. When this happens execution in the current block terminates and control is passed to the exception section. Unless you deliberately plan to handle this scenario use of the implicit cursor is a declaration of faith. You are saying I trust that query to always return a single row It may well be that today with the current data the query will only return a single row. If the nature of the data ever changes however you may find that the SELECT statement which formerly identified a single row now returns several. Your program will raise an exception. Perhaps this is what you will want. On the other hand perhaps the presence of additional records is inconsequential and should be ignored. With the implicit query you cannot easily handle these different possibilities. With an explicit query your program will be protected against changes in data and will continue to fetch rows without raising exceptions. 6.3.2.3 Diminished programmatic control The implicit cursor version of a SELECT statement is a black box. You pass the SQL statement to the SQL layer in the database and it returns you hope a single row. You can t get inside the separate operations of the cursor such as the open and close stages. You can t examine the attributes of the cursor -- to see whether a row was found for example or if the cursor has already been opened. You can t easily apply traditional programming control constructs such as an IF statement to your data access. Sometimes you don t need this level of control. Sometimes you just think you don t need this level of control. I have found that if I am going to build programs in PL SQL I want as much control as I can possibly get. Always Use Explicit Cursors My rule of thumb is always to use an explicit cursor for all SELECT statements in my applications even if an implicit cursor might run a little bit faster