Database and SQL

When accessing DB2 database tables from a COBOL program, any host variable referenced inside an EXEC SQL block must be prefixed with a colon (:) to distinguish it from DB2 table column names. Using semicolons or omitting the prefix entirely will cause compilation errors.

In DB2 SQL, -904 indicates a resource unavailable error, -818 represents a timestamp mismatch between plan and program, -181 indicates an invalid datetime format, -803 represents a duplicate key violation, and -911 indicates a deadlock or timeout. Option A matches all codes correctly.

SQL requires the "FOR UPDATE OF" clause when declaring a cursor that will be used to update rows. This specifies which columns can be updated through the cursor and is necessary for positioned updates using UPDATE...WHERE CURRENT OF.

SUM FIELDS=NONE in JCL/SORT eliminates duplicate records by keeping only one instance when multiple records have matching sort keys. Unlike SUM FIELDS with numeric fields (which sums values), FIELDS=NONE simply discards duplicates, yielding unique records.

The SQL query uses concatenation (||) to combine address1, a comma, address2, another comma, and address2 again into a single column with alias 'Adress'. Regardless of how many source columns are concatenated, the result set contains exactly one column named 'Adress'.

In Oracle SQL (and most databases), unquoted column names must start with a letter, not a number. '1966_Invoices' starts with a number making it invalid. '#Invoices' starts with a special character. 'Catch_#22' is valid because it starts with a letter and contains only allowed characters (letters, digits, underscore, hash). 'Column' may be a reserved keyword but can be used as a column name without quoting in Oracle.

In a cursor declaration, the INTO clause is not part of the SELECT statement. The INTO clause is used with explicit cursors only when combined with a FETCH statement to retrieve rows into variables. A cursor definition should only contain SELECT-FROM-WHERE (and other clauses like GROUP BY, ORDER BY), but not INTO.

In PL/SQL, a SELECT INTO statement raises a NO_DATA_FOUND exception if it returns zero rows, and a TOO_MANY_ROWS exception if it returns more than one row. Mismatched datatypes raise different runtime errors, while a missing INTO clause is a syntax/compilation error rather than a raised runtime exception.

The NEXT_DAY function returns the first occurrence of a given day of the week that is strictly after the input date. Since today (sysdate) is Monday, July 10, 2000, NEXT_DAY returns the following Monday, July 17, 2000. The to_char with 'DD-MON-RR' formats this as '17-JUL-00'. Note that RR handles year 2000 dates in a specific way.

High selectivity in SQL means the query predicate filters out most rows, returning only a FEW rows from the table. Selectivity is the ratio of rows returned to total rows - high selectivity means a small ratio (few rows), which is good for index usage. Low selectivity means many rows are returned, often making full table scans more efficient.

SELECT * should be avoided because: 1) it can cause unnecessary full table scans when only specific columns are needed (option A), and 2) it retrieves all columns, increasing network traffic between database and application (option C). Using SELECT * doesn't inherently cause index scans (actually often prevents them) or cartesian joins.

When an AXA_RT_Application_Demand request type integrated with Augeo is created, records are inserted into both Augeo custom tables: AXA_AUGEO_TASKS_CURR_STATUS (for tracking current status) and AXA_AUGEO_TASKS_FLOW (for tracking workflow/flow information). This dual-table approach maintains both status and flow state for integration purposes.

In HP PPM's database schema, KCRT_REQUESTS, KCRT_REQ_HEADER_DETAILS, and KCRT_REQUEST_DETAILS are valid table names. However, KCRT_REQUESTS_TYPES is not a standard table name - the naming convention would typically use REQUEST_TYPE (singular) or a different naming pattern. This question tests knowledge of the actual PPM database schema.

The default value for 'Business Approver' in AXA_RT_Application_Demand's Ownership section inherits from 'Primary Business Approver' in AXA_RT_Application_Definition's Application section. This represents a parent-child relationship where application definition settings flow down to specific demand requests.

SQL return code -180 indicates an invalid date or time specification. This error occurs when a date, time, or timestamp value does not conform to the expected format or contains invalid values.