Search Results get_dates

Overview

APPS.DT_PKG is a small server-side PL/SQL agent package belonging to the Oracle E-Business Suite HR Libraries subsystem (the DT prefix denotes the "Date" library lineage). Its stated purpose, per the package header, is to handle all server-side traffic to and from Oracle Forms libraries. This indirection exists to avoid a specific and well-known failure mode in the Oracle Forms runtime: when a form and its attached libraries both reference the same server-side package, Forms can behave unpredictably. By interposing a thin server-side agent, the HR Libraries code can isolate date-handling calls behind a stable interface that the client-side libraries invoke, rather than allowing each library to reach directly into the underlying DT_FNDATE package.

The body carries a version header string of dt.pkb 115.1, dated 09-Dec-2002, attributed to A. Holt, with the comment "NOCOPY Performance Changes for 11.5.9." The package was originally created 21 Apr 1995 by N Simpson, and a 110.1 revision in September 1997 by Khabibul addressed a 255-character width problem. These history entries confirm the package's long life across the 11.5.x and 12.x releases, and its continued presence in 12.1.1 and 12.2.2, where the source remains essentially unchanged from the 11.5.9 baseline. In ETRM it is classified as API classification OTHER, with no tables referenced through APPS synonyms and no other packages documented as calling it.

Key Procedures and Functions

Exactly one procedure is documented in the package body: GET_DATES.

• GET_DATES — A public wrapper procedure that exposes the date-derivation logic of the underlying DT_FNDATE package to Forms libraries. It declares six OUT NOCOPY parameters: the session date, the session "yesterday" date, the start-of-time date, the end-of-time date, the system date, and a commit indicator. The body consists solely of a pass-through call to DT_FNDATE.GET_DATES, forwarding all six parameters positionally in the same order in which they are declared. No local computation, validation, or exception handling is performed; the procedure's entire value is the indirection layer itself.

The use of OUT NOCOPY on every parameter is the substance of the 115.1 revision: NOCOPY passes the actual by reference where possible rather than copying the value on entry and exit, reducing PGA and latch overhead for callers that invoke GET_DATES frequently within a session. For DATE-typed scalars the runtime may still copy, but the declaration follows the 11.5.9 performance convention applied across the HR Libraries packages.

Tables Accessed

The documented metadata records no tables referenced via APPS synonyms, and this is consistent with the source: the body contains no SQL statements whatsoever. All data acquisition is delegated to DT_FNDATE.GET_DATES, which is not part of this package and is therefore outside the documented scope. GET_DATES is a pure pass-through, so any table or profile-based access occurs downstream in DT_FNDATE, not here. Users auditing DT_PKG for database dependencies should follow the call chain into DT_FNDATE rather than expecting direct access from this body.

Usage Notes

DT_PKG is invoked from the client side of Oracle Forms, most likely from the HR Libraries PL/SQL program units that need the standard EBS date set — session date, prior-day date, start and end of time, and system date — together with the commit flag used to determine whether the caller may commit. This pattern is common in HRMS and other date-sensitive forms, where a consistent notion of "today" and of the configured date boundaries must be shared between the form and the database.

Because the package is an agent, it should be treated as an internal implementation detail rather than a public integration API. Custom code that needs the same date values should generally call the underlying date utility used by the application, or query the relevant profile options directly, rather than depending on the DT_PKG wrapper, whose signature exists to satisfy a Forms-runtime constraint rather than to define a supported interface. Note that in 12.2.2 the package remains delivered in its 11.5.x form; no 12.x-specific revisions appear in the header history, so behavior is expected to be identical across 12.1.1 and 12.2.2.