Reporting Database Refresh

B

Bill Busby

How often and what triggers refreshes to the reporting database? I've done
some testing and observed that entries to timesheets that don't require
approval are added to the reporting database in near-real time. On tasks that
I've accepted and updated in project plans the time didn't migrate to the
reporting database until the plan was republished. That last bit would be a
killer if it holds true since we plan to automate a large percentage of time
updates and these projects won't be republished.
 
S

Sharry Heberer [MSFT]

The main entities that trigger a Reporting job to be placed placed in the
Queue are:
Projects (triggering action: *only* on a project publish, to ensure that the
PM has control over what goes in to the reporting DB and when)
Resources (triggering action: create/edit/delete)
Custom Fields (triggering action: create/edit/delete)
Lookup Tables (triggering action: create/edit/delete)
Timesheets (triggering action: create/edit/delete/status changes such as
submit/recall)
Timesheet Periods (triggering action: create/edit/delete)
Timesheet Classes (triggering action: create/edit/delete)
Fiscal Periods (triggering action: create/edit/delete)
Project Workspace Issues/Risks/Deliverables (triggering action: only on a
project publish or a Workspace Sync to ensure that the PM has control over
what goes in to the RDB and when)

Other miscellaneous jobs are placed in the Queue for the Reporting System to
be able to calculate certain things correctly, such as Calendar changes
which would impact Resource Capacity. If you need more details on some of
the other miscellaneous jobs, let me know what you're interested in.

Hope this helps,
Sharry
 
B

Bill Busby

Great info, would love to see it documented somewhere or am I missing it? I
get your point on PM control but most of our project managers are quasi-PM's
who will never likely understand the connection to republishing a project and
making the data available in the reporting database. In Project Server 2003
we had issues with PM's not approving time so our reports always had a delta
in them, now we seem to be introducing another opportunity for delta's based
on our PM's not republishing their project after accepting time. I for one
would never have made the connection that a republish was needed to make the
data I just approved available for reports. Is is conceivable to automate a
republish to some event triggered with accepting time?
 
S

Sharry Heberer [MSFT]

I'm not sure if the RDB triggers are documented anywhere. I would assume
so, but I'm not sure.

There should be an appropriate event you can trigger a publish from after
time is accepted, if that's what your org really wants to do. I think this
would be an acceptable approach, as long as the correct permissions are in
place. But I'm not the expert in Task Management, so I can't comment on
whether there would be any fallout or "gotchas" by doing this. I guess my
biggest concern here would be that the project would be published and the PM
wouldn't know how the schedule might have been impacted by the recent
updates to time. But if your org doesn't care about that, then maybe it's
the appropriate solution for you.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Top