Thanks for posting this; I was able to use this information as a starting point to write my own (primitive but reasonably effective) set of queries.

Have you checked out sdd_version_associations? It has a date_changed column that *does* behave reasonably: it gets updated when an *existing* object is versioned. Between sdd_version_associations and I$SDD_OBJECT_VERSIONS I’m able to get a pretty good picture of versioning activity, without adding a trigger anywhere. Here’s a quick report of recent versioning of existing objects:

select trunc(date_changed), count(*) from sdd_version_associations
where date_changed >= trunc(sysdate – 3)
group by trunc(date_changed) order by trunc(date_changed) asc;

Also, you are probably aware of this already but I thought I’d mention the fact that Designer registers user/session information with v$session via the dbms_application_info package:

column username format a20
column module format a40
column action format a30
set linesize 99

–This works because Designer registers with v$session via the DBMS_APPLICATION_INFO package
select username, module, action from v$session where username is not null
order by username, module;

I have also found the following useful in reporting Designer activity (I use them in a LOOP):

jr_version.is_any_version_checked_out(v_irid)
jr_name.get_path_no_context(X.ivid, ‘MAIN’,'VLABELTYPE’,'/’,0);

One last thing: I’ve been using I$SDD_FOLDERS instead of CI_APPLICATION_SYSTEMS.

Referencing only the things I’ve posted here I’ve written a primitive yet effective set of “dashboard” queries:

1. “big picture” stuff: number of elements per folder, etc.
2. who’s logged into Designer and what they’re currently doing
3. Current checkouts (elements and containers)
4. Recently created objects
5. Recently versioned existing objects

I’ll post the whole thing if it’s of interest; if not I don’t want to clutter up your blog

Oh – any tips for reporting on deleted elements and containers?

*Thanks again* I feel so much more secure now, because I can tell what’s going on in my Repository without having to walk around and ask people!

So my alternative approach is to abuse column COMMENTS in table i$sdd_object_versions that does not seem to be used at all. Use this column to keep track of the most recent change to the object version:

CREATE OR REPLACE TRIGGER I$SDD_OBJECT_VERSIONS_NOTM
BEFORE UPDATE
OF OBJ_NOTM
ON I$SDD_OBJECT_VERSIONS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
/******************************************************************************
NAME: I$SDD_OBJECT_VERSIONS_NOTM
PURPOSE: Ensure that DATE_CHANGED is updated whenever OBJ_NOTM is updated
REVISIONS:
Ver Date Author Description
——— ———- ————— ————————————
1.2 10/02/2005 Lucas Replaced new columns with use of column COMMENTS;
note: new columns are not feasible as some INSERT statements in core SCM code do not
list column names and will therefore fail with too few values provided!
1.1 10/02/2005 Lucas Added support for new columns OBJ_DATE_CHANGED and OBJ_CHANGED_BY
1.0 9/28/2005 Lucas Created this trigger.
NOTES: This is an unsupported extension to Oracle 10g SCM

******************************************************************************/ BEGIN
:new.comments := to_char(SYSDATE,’DD-MM-YYYY HH24:MI:SS’)||USER;
END ;
/
This allows me to see the last time the object version state was changed (merge, check in) as well as the last time the underlying Designer object itself was modified. With the previously proposed solution, I could not have discerned between the check in date and the last modified date.

CREATE OR REPLACE TRIGGER I$SDD_OBJECT_VERSIONS_NOTM
BEFORE UPDATE
OF OBJ_NOTM
ON I$SDD_OBJECT_VERSIONS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
/******************************************************************************
NAME: I$SDD_OBJECT_VERSIONS_NOTM
PURPOSE: Ensure that DATE_CHANGED is updated whenever OBJ_NOTM is updated
REVISIONS:
Ver Date Author Description
——— ———- ————— ————————————
1.1 10/02/2005 Lucas Added support for new columns OBJ_DATE_CHANGED and OBJ_CHANGED_BY
1.0 9/28/2005 Lucas Created this trigger.
NOTES: This is an unsupported extension to Oracle 10g SCM

******************************************************************************/ BEGIN
:new.OBJ_DATE_CHANGED := SYSDATE;
:new.OBJ_CHANGED_BY := USER;
END ;
/
This allows me to see the last time the object version state was changed (merge, check in) as well as the last time the underlying Designer object itself was modified. With the previously proposed solution, I could not have discerned between the check in date and the last modified date.