Defaulting Null Values in an outer join to the last joined row's values.

Question

I have a situation where I need to fill in the missing values from an outer join with the last values returned by the join.
The query is based on a date table, an organization table and a transaction table.
SELECT D.DATE_ID, O.ORG_ID, T.VALUE
FROM D_ORGANIZATION O, D_DATE D, F_TRANSACTION T
WHERE D.DATE_ID = T.DATE_ID(+)
AND T.ORG_ID = O.ORG_ID(+)
AND O.ORG_NAME = '&NAME'[
AND D.THE_DATE >= ADD_MONTHS( TO_DATE( '&&PERIOD_DATE', 'DD-MON-YYYY' ), -23 )
AND D.THE_DATE <= ADD_MONTHS( TO_DATE( '&&PERIOD_DATE', 'DD-MON-YYYY' ), 24 )
So the query will return all dates in the 4 year period, and where transactions exist the relevent value.
DATE_ID ORG_ID VALUE
38291     2 99.8
38321     2 45.1
38352     
38383     
38411     
What I need to happen is:
DATE_ID ORG_ID VALUE
38291     2 99.8
38321     2 45.1
38352     2 45.1     
38383 2 45.1
38411     2 45.1
Lag appears to be of no use because it will only pick up the last genuine value, so using
NVL(T.VALUE, LAG(T.VALUE,1) OVER ( .... )
Gives:
ATE_ID ORG_ID VALUE
38291     2 99.8
38321     2 45.1
38352     2 45.1     
38383
38411     
The length of the data gap can vary as constituent organisations don't all return their data at the same time, and there may be intermediate dates where no data is returned , but the value needs to be calculated.
What's going on here is that a gaph is being generated where the tool requires data points to plot the line, once the real data ends a bespoke trend calculations takes over based on the last value returned. I do not have access to the data warehousing options so a solution that doen't need them would be handy, but if not then options can be purchased.
The tool can't use PL/SQL, but is perhaps a bespoke function in order?

Answer 1

To do this wouldn't you need to know the data in advance? The real source table had 1800 organisations and 8,000,000 transactions.
I Tried this as well, creating a pl/sql package as follows.
create or replace PACKAGE stack AS
TYPE gnt_push_numbers IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
TYPE gvt_push_varchars IS TABLE OF VARCHAR(1000) INDEX BY PLS_INTEGER;
gna_push_numbers gnt_push_numbers;
gva_push_varchars gvt_push_varchars;
FUNCTION PUSH ( pn_push_var NUMBER, pn_offset NUMBER) RETURN NUMBER DETERMINISTIC;
FUNCTION PUSH ( pv_push_var VARCHAR, pn_offset NUMBER) RETURN VARCHAR DETERMINISTIC;
FUNCTION POP_NUM ( pn_offset NUMBER) RETURN NUMBER DETERMINISTIC;
FUNCTION POP_VAR ( pn_offset NUMBER) RETURN VARCHAR DETERMINISTIC;
END stack;
CREATE OR REPLACE
PACKAGE BODY "STACK" AS
FUNCTION push(pn_push_var NUMBER, pn_offset NUMBER) RETURN NUMBER deterministic IS
BEGIN
gna_push_numbers(pn_offset) := pn_push_var;
RETURN pn_push_var;
END push;
FUNCTION push(pv_push_var VARCHAR, pn_offset NUMBER) RETURN VARCHAR deterministic IS
BEGIN
gva_push_varchars(pn_offset) := pv_push_var;
RETURN pv_push_var;
END push;
FUNCTION pop_num(pn_offset NUMBER) RETURN NUMBER deterministic IS
BEGIN
RETURN gna_push_numbers(pn_offset);
END pop_num;
FUNCTION pop_var(pn_offset NUMBER) RETURN VARCHAR deterministic IS
BEGIN
RETURN gva_push_varchars(pn_offset);
END pop_var;
END stack;
Unfortunately it appears to act before the rows are sorted, so will only work in specialised circumstances, in that you have to ensure the rows have been sorted before the function is used.
SELECT PUSH(COL), POP..(COL)
FROM ( SELECT etc.
Luckily the client decided they didn't want to mix their graphs any more so a more classic approach using a base table select for actuals and then a date table select with a sub-query columns for the projection provided a simple solution.