1 Package pqh_doa_shd AUTHID CURRENT_USER as
2 /* $Header: pqdoarhi.pkh 120.0 2005/05/29 01:49:09 appldev noship $ */
3 --
4 -- ----------------------------------------------------------------------------
5 -- | Global Record Type Specification |
6 -- ----------------------------------------------------------------------------
7 --
8 Type g_rec_type Is Record
9 (document_attribute_id number(9) -- Increased length
10 ,effective_start_date date
11 ,effective_end_date date
12 ,document_id number(15)
13 ,attribute_id number(15)
14 ,tag_name varchar2(240)
15 ,object_version_number number(9)
16 );
17 --
18 -- ----------------------------------------------------------------------------
19 -- | Global Definitions - Internal Development Use Only |
20 -- ----------------------------------------------------------------------------
21 --
22 g_old_rec g_rec_type; -- Global record definition
23 -- Global table name
24 g_tab_nam constant varchar2(30) := 'PQH_DOCUMENT_ATTRIBUTES_F';
25 g_api_dml boolean; -- Global api dml status
26 --
27 -- ----------------------------------------------------------------------------
28 -- |------------------------< return_api_dml_status >-------------------------|
29 -- ----------------------------------------------------------------------------
30 -- {Start Of Comments}
31 --
32 -- Description:
33 -- This function will return the current g_api_dml private global
34 -- boolean status.
35 -- The g_api_dml status determines if at the time of the function
36 -- being executed if a dml statement (i.e. INSERT, UPDATE or DELETE)
37 -- is being issued from within an api.
38 -- If the status is TRUE then a dml statement is being issued from
39 -- within this entity api.
40 -- This function is primarily to support database triggers which
41 -- need to maintain the object_version_number for non-supported
42 -- dml statements (i.e. dml statement issued outside of the api layer).
43 --
44 -- Prerequisites:
45 -- None.
46 --
47 -- In Parameters:
48 -- None.
49 --
50 -- Post Success:
51 -- Processing continues.
52 -- If the function returns a TRUE value then, dml is being executed from
53 -- within this api.
54 --
55 -- Post Failure:
56 -- None.
57 --
58 -- Access Status:
59 -- Internal Row Handler Use Only.
60 --
61 -- {End Of Comments}
62 -- ----------------------------------------------------------------------------
63 Function return_api_dml_status Return Boolean;
64 --
65 -- ----------------------------------------------------------------------------
66 -- |---------------------------< constraint_error >---------------------------|
67 -- ----------------------------------------------------------------------------
68 -- {Start Of Comments}
69 --
70 -- Description:
71 -- This procedure is called when a constraint has been violated (i.e.
72 -- The exception hr_api.check_integrity_violated,
73 -- hr_api.parent_integrity_violated, hr_api.child_integrity_violated or
74 -- hr_api.unique_integrity_violated has been raised).
75 -- The exceptions can only be raised as follows:
76 -- 1) A check constraint can only be violated during an INSERT or UPDATE
77 -- dml operation.
78 -- 2) A parent integrity constraint can only be violated during an
79 -- INSERT or UPDATE dml operation.
80 -- 3) A child integrity constraint can only be violated during an
81 -- DELETE dml operation.
82 -- 4) A unique integrity constraint can only be violated during INSERT or
83 -- UPDATE dml operation.
84 --
85 -- Prerequisites:
86 -- 1) Either hr_api.check_integrity_violated,
87 -- hr_api.parent_integrity_violated, hr_api.child_integrity_violated or
88 -- hr_api.unique_integrity_violated has been raised with the subsequent
89 -- stripping of the constraint name from the generated error message
90 -- text.
91 -- 2) Standalone validation test which corresponds with a constraint error.
92 --
93 -- In Parameter:
94 -- p_constraint_name is in upper format and is just the constraint name
95 -- (e.g. not prefixed by brackets, schema owner etc).
96 --
97 -- Post Success:
98 -- Development dependant.
99 --
100 -- Post Failure:
101 -- Developement dependant.
102 --
103 -- Developer Implementation Notes:
104 -- For each constraint being checked the hr system package failure message
105 -- has been generated as a template only. These system error messages should
106 -- be modified as required (i.e. change the system failure message to a user
107 -- friendly defined error message).
108 --
109 -- Access Status:
110 -- Internal Development Use Only.
111 --
112 -- {End Of Comments}
113 -- ----------------------------------------------------------------------------
114 Procedure constraint_error
115 (p_constraint_name in all_constraints.constraint_name%TYPE);
116 --
117 -- ----------------------------------------------------------------------------
118 -- |-----------------------------< api_updating >-----------------------------|
119 -- ----------------------------------------------------------------------------
120 -- {Start Of Comments}
121 --
122 -- Description:
123 -- This function is used to populate the g_old_rec record with the
124 -- current row from the database for the specified primary key
125 -- provided that the primary key exists and is valid and does not
126 -- already match the current g_old_rec. The function will always return
127 -- a TRUE value if the g_old_rec is populated with the current row.
128 -- A FALSE value will be returned if all of the primary key arguments
129 -- are null.
130 --
131 -- Prerequisites:
132 -- None.
133 --
134 -- In Parameters:
135 --
136 -- Post Success:
137 -- A value of TRUE will be returned indiciating that the g_old_rec
138 -- is current.
139 -- A value of FALSE will be returned if all of the primary key arguments
140 -- have a null value (this indicates that the row has not be inserted into
141 -- the Schema), and therefore could never have a corresponding row.
142 --
143 -- Post Failure:
144 -- A failure can only occur under two circumstances:
145 -- 1) The primary key is invalid (i.e. a row does not exist for the
146 -- specified primary key values).
147 -- 2) If an object_version_number exists but is NOT the same as the current
148 -- g_old_rec value.
149 --
150 -- Developer Implementation Notes:
151 -- None.
152 --
153 -- Access Status:
154 -- Internal Development Use Only.
155 --
156 -- {End Of Comments}
157 -- ----------------------------------------------------------------------------
158 Function api_updating
159 (p_effective_date in date
160 ,p_document_attribute_id in number
161 ,p_object_version_number in number
162 ) Return Boolean;
163 --
164 -- ----------------------------------------------------------------------------
165 -- |---------------------------< find_dt_upd_modes >--------------------------|
166 -- ----------------------------------------------------------------------------
167 -- {Start Of Comments}
168 --
169 -- Description:
170 -- This procedure is used to determine what datetrack update modes are
171 -- allowed as of the effective date for this entity. The procedure will
172 -- return a corresponding Boolean value for each of the update modes
173 -- available where TRUE indicates that the corresponding update mode
174 -- is available.
175 --
176 -- Prerequisites:
177 -- None.
178 --
179 -- In Parameters:
180 -- p_effective_date
181 -- Specifies the date at which the datetrack modes will be operated on.
182 -- p_base_key_value
183 -- Specifies the primary key value for this datetrack entity.
184 -- (E.g. For this entity the assignment of the argument would be:
185 -- p_base_key_value = :document_attribute_id).
186 --
187 -- Post Success:
188 -- Processing continues.
189 --
190 -- Post Failure:
191 -- Failure might occur if for the specified effective date and primary key
192 -- value a row doesn't exist.
193 --
194 -- Developer Implementation Notes:
195 -- This procedure could require changes if this entity has any sepcific
196 -- delete restrictions.
197 -- For example, this entity might disallow the datetrack update mode of
198 -- UPDATE. To implement this you would have to set and return a Boolean
199 -- value of FALSE after the call to the dt_api.find_dt_upd_modes procedure.
200 --
201 -- Access Status:
202 -- Internal Development Use Only.
203 --
204 -- {End Of Comments}
205 -- ----------------------------------------------------------------------------
206 Procedure find_dt_upd_modes
207 (p_effective_date in date
208 ,p_base_key_value in number
209 ,p_correction out nocopy boolean
210 ,p_update out nocopy boolean
211 ,p_update_override out nocopy boolean
212 ,p_update_change_insert out nocopy boolean
213 );
214 --
215 -- ----------------------------------------------------------------------------
216 -- |---------------------------< find_dt_del_modes >--------------------------|
217 -- ----------------------------------------------------------------------------
218 -- {Start Of Comments}
219 --
220 -- Description:
221 -- This procedure is used to determine what datetrack delete modes are
222 -- allowed as of the effective date for this entity. The procedure will
223 -- return a corresponding Boolean value for each of the delete modes
224 -- available where TRUE indicates that the corresponding delete mode is
225 -- available.
226 --
227 -- Prerequisites:
228 -- None.
229 --
230 -- In Parameters:
231 -- p_effective_date
232 -- Specifies the date at which the datetrack modes will be operated on.
233 -- p_base_key_value
234 -- Specifies the primary key value for this datetrack entity.
235 -- (E.g. For this entity the assignment of the argument would be:
236 -- p_base_key_value = :document_attribute_id).
237 --
238 -- Post Success:
239 -- Processing continues.
240 --
241 -- Post Failure:
242 -- Failure might occur if for the specified effective date and primary key
243 -- value a row doesn't exist.
244 --
245 -- Developer Implementation Notes:
246 -- This procedure could require changes if this entity has any sepcific
247 -- delete restrictions.
248 -- For example, this entity might disallow the datetrack delete mode of
249 -- ZAP. To implement this you would have to set and return a Boolean value
250 -- of FALSE after the call to the dt_api.find_dt_del_modes procedure.
251 --
252 -- Access Status:
253 -- Internal Development Use Only.
254 --
255 -- {End Of Comments}
256 -- ----------------------------------------------------------------------------
257 Procedure find_dt_del_modes
258 (p_effective_date in date
259 ,p_base_key_value in number
260 ,p_zap out nocopy boolean
261 ,p_delete out nocopy boolean
262 ,p_future_change out nocopy boolean
263 ,p_delete_next_change out nocopy boolean
264 );
265 --
266 -- ----------------------------------------------------------------------------
267 -- |-----------------------< upd_effective_end_date >-------------------------|
268 -- ----------------------------------------------------------------------------
269 -- {Start Of Comments}
270 --
271 -- Description:
272 -- This procedure will update the specified datetrack row with the
273 -- specified new effective end date. The object version number is also
274 -- set to the next object version number. DateTrack modes which call
275 -- this procedure are: UPDATE, UPDATE_CHANGE_INSERT,
276 -- UPDATE_OVERRIDE, DELETE, FUTURE_CHANGE and DELETE_NEXT_CHANGE.
277 -- This is an internal datetrack maintenance procedure which should
278 -- not be modified in anyway.
279 --
280 -- Prerequisites:
281 -- None.
282 --
283 -- In Parameters:
284 -- p_new_effective_end_date
285 -- Specifies the new effective end date which will be set for the
286 -- row as of the effective date.
287 -- p_base_key_value
288 -- Specifies the primary key value for this datetrack entity.
289 -- (E.g. For this entity the assignment of the argument would be:
290 -- p_base_key_value = :document_attribute_id).
291 --
292 -- Post Success:
293 -- The specified row will be updated with the new effective end date and
294 -- object_version_number.
295 --
296 -- Post Failure:
297 -- Failure might occur if for the specified effective date and primary key
298 -- value a row doesn't exist.
299 --
300 -- Developer Implementation Notes:
301 -- This is an internal datetrack maintenance procedure which should
302 -- not be modified in anyway.
303 --
304 -- Access Status:
305 -- Internal Row Handler Use Only.
306 --
307 -- {End Of Comments}
308 -- ----------------------------------------------------------------------------
309 Procedure upd_effective_end_date
310 (p_effective_date in date
311 ,p_base_key_value in number
312 ,p_new_effective_end_date in date
313 ,p_validation_start_date in date
314 ,p_validation_end_date in date
315 ,p_object_version_number out nocopy number
316 );
317 --
318 -- ----------------------------------------------------------------------------
319 -- |---------------------------------< lck >----------------------------------|
320 -- ----------------------------------------------------------------------------
324 -- The Lck process for datetrack is complicated and comprises of the
321 -- {Start Of Comments}
322 --
323 -- Description:
325 -- following processing
326 -- The processing steps are as follows:
327 -- 1) The row to be updated or deleted must be locked.
328 -- By locking this row, the g_old_rec record data type is populated.
329 -- 2) If a comment exists the text is selected from hr_comments.
330 -- 3) The datetrack mode is then validated to ensure the operation is
331 -- valid. If the mode is valid the validation start and end dates for
332 -- the mode will be derived and returned. Any required locking is
333 -- completed when the datetrack mode is validated.
334 --
335 -- Prerequisites:
336 -- When attempting to call the lck procedure the object version number,
337 -- primary key, effective date and datetrack mode must be specified.
338 --
339 -- In Parameters:
340 -- p_effective_date
341 -- Specifies the date of the datetrack update operation.
342 -- p_datetrack_mode
343 -- Determines the datetrack update or delete mode.
344 --
345 -- Post Success:
346 -- On successful completion of the Lck process the row to be updated or
347 -- deleted will be locked and selected into the global data structure
348 -- g_old_rec.
349 --
350 -- Post Failure:
351 -- The Lck process can fail for three reasons:
352 -- 1) When attempting to lock the row the row could already be locked by
353 -- another user. This will raise the HR_Api.Object_Locked exception.
354 -- 2) The row which is required to be locked doesn't exist in the HR Schema.
355 -- This error is trapped and reported using the message name
356 -- 'HR_7220_INVALID_PRIMARY_KEY'.
357 -- 3) The row although existing in the HR Schema has a different object
358 -- version number than the object version number specified.
359 -- This error is trapped and reported using the message name
360 -- 'HR_7155_OBJECT_INVALID'.
361 --
362 -- Developer Implementation Notes:
363 -- None.
364 --
365 -- Access Status:
366 -- Internal Development Use Only.
367 --
368 -- {End Of Comments}
369 -- ----------------------------------------------------------------------------
370 Procedure lck
371 (p_effective_date in date
372 ,p_datetrack_mode in varchar2
373 ,p_document_attribute_id in number
374 ,p_object_version_number in number
375 ,p_validation_start_date out nocopy date
376 ,p_validation_end_date out nocopy date
377 );
378 --
379 -- ----------------------------------------------------------------------------
380 -- |-----------------------------< convert_args >-----------------------------|
381 -- ----------------------------------------------------------------------------
382 -- {Start Of Comments}
383 --
384 -- Description:
385 -- This function is used to turn attribute parameters into the record
386 -- structure parameter g_rec_type.
387 --
388 -- Prerequisites:
389 -- This is a private function and can only be called from the ins or upd
390 -- attribute processes.
391 --
392 -- In Parameters:
393 --
394 -- Post Success:
395 -- A returning record structure will be returned.
396 --
397 -- Post Failure:
398 -- No direct error handling is required within this function. Any possible
399 -- errors within this function will be a PL/SQL value error due to
400 -- conversion of datatypes or data lengths.
401 --
402 -- Developer Implementation Notes:
403 -- None.
404 --
405 -- Access Status:
406 -- Internal Row Handler Use Only.
407 --
408 -- {End Of Comments}
409 -- ----------------------------------------------------------------------------
410 Function convert_args
411 (p_document_attribute_id in number
412 ,p_effective_start_date in date
413 ,p_effective_end_date in date
414 ,p_document_id in number
415 ,p_attribute_id in number
416 ,p_tag_name in varchar2
417 ,p_object_version_number in number
418 )
419 Return g_rec_type;
420 --
421 end pqh_doa_shd;
[Home] [Help]