Database and SQL

Move by name copies the values from fields with matching column names in the source structure to the target structure. It does not reset values or perform copy-then-reset operations.

The record-required parameter is specific to Explicit join type in Ab Initio. It specifies how many input flows must contribute a record for output to be generated. This parameter doesn't apply to Implicit joins where the join conditions define the relationship.

When input_select returns NULL in a Normalize component, three actions occur: the record goes to the reject port, an error message is written to the error port, and if these ports aren't connected, the record is silently discarded. This is the standard error handling behavior.

True - query filters can be made optional in reporting tools. Optional filters allow reports to run even if the user doesn't provide a value for that filter, providing flexibility in report execution.

In Asset Control, custom validation rules for incoming feed data are extended by creating and applying Formulas. While features like Compound Attributes define data relationships and the Table Editor allows manual data modifications, only Formulas are used to programmatically evaluate and enforce validation constraints.

Subquery results cannot be stored in the query result cache because they represent intermediate results, making option A correct. Queries with SYSDATE function cannot be cached since SYSDATE returns different values on each execution, making option B correct. GROUP BY results and static DATE conditions in WHERE clauses can be cached, so options C and D are incorrect.

Using bind arguments is a primary defense against SQL injection because it separates SQL logic from data values, preventing malicious input from altering SQL structure. Option A is incorrect because package subprograms alone don't prevent injection. Option B is incorrect because concatenation actually increases vulnerability. Option D about NOT NULL constraint is irrelevant to SQL injection security.

SYS_REFCURSOR is a pre-defined weak REF CURSOR type that can be used to declare cursor variables in stored procedures and functions, making option B correct. REF CURSOR return types can be declared using %TYPE, %ROWTYPE, or user-defined records, making option C correct. Option A is incorrect because REF CURSOR types can be defined inside packages. Option D is incorrect because both weak and strong REF CURSOR types can be used as formal parameters.

For a PL/SQL function to be cached, it must not be defined in an anonymous block (which are transient), making option C correct. It must have at least one OUT or IN OUT parameter to support result caching, making option D correct. Option A is incorrect because standalone functions can also be cached. Option B is incorrect because pipelined table functions are not eligible for result caching.

In SQL, the WHERE clause specifies filtering criteria to restrict which rows are returned. In PeopleSoft Query, when you add criteria/conditions to filter data, these translate directly to WHERE clause conditions in the generated SQL. SELECT specifies columns, FROM specifies tables, GET and IMPORT are not SQL clauses.

SavePostChange is the PeopleCode event that fires immediately after the Component Processor has successfully updated the database. SaveEdit and SavePreChange fire before the database updates are committed, and SearchSave is triggered during the search process before the component is loaded.

In PeopleSoft Query, when you specify criteria to filter records, it translates to the WHERE clause in SQL. The WHERE clause filters rows based on conditions, which is exactly what query criteria do. SELECT specifies columns, FROM specifies tables, and WHERE is for filtering conditions.

After the Component Processor updates the database successfully, it fires the SavePostChange PeopleCode event. SavePreChange fires before the update, SaveEdit is for validation, and SearchSave is for saving search dialog box data. SavePostChange is used for post-processing after data commit.

To find the 2nd maximum value, we need to find the maximum value from the set of records that excludes the overall maximum. The query in option C correctly does this: the subquery gets MAX(field4) WHERE field4 is NOT IN the list containing the single maximum value. This returns the second highest value. Options A and B use MIN incorrectly in the subquery, which would give the minimum value, not the second maximum.

Correlated subqueries can often replace row-by-row cursor operations and significantly improve performance. Cursors are slow because they process one row at a time with frequent context switching. A correlated subquery executes set-based operations which are optimized by the query engine. Indexes (option B) improve data access but don't replace row-by-row logic. TOP() (option C) returns a specified number of rows but doesn't perform row-by-row operations.