The problem, described shortly is:

1. you have 2 databases in MS SQL residing on the same physical server

2. you create a join “table A from db1 with table B from db2”

3. Cognos creates two select queries (select * from db1.A) and (select * from db2.B) and then does join locally on server. That’s terribly slow. Cognos should be generating one select query, performing the join on the db server and that’d be really fast.

The answer is simple: there’s no way Cognos can find out that these two databases are on the same physical server. But we can help old fella a bit, setting a datasource property (Content Manager Datasource) the same for both datasources. Therefore, the same datasource prefix will be generated for both tables and they’ll be regarded as residing on the same server. Query speed will increase dramatically.

Morale:  always set the datasource property for MS SQL databases located on the same server. 

Gave me some trouble recently, when language changes led to unappropriate publish folder name. Moreover, we were not able to publish anything at all )

Changing this file helped. Found via FileMonitor from sysinternals, as usual.

I really expect and encourage comments on this naming proposal. Maybe together we will create something like Sun Java Code Conventions )

Whoa, it's a really huge document, maybe I'll it finish someday...

[1]: http://www.amazon.com/OLAP-Solutions-Building-Multidimensional-Information/dp/0471400300

See how incremental publish can streamline your reporting in these posts: 1, 2.

Create time dimension so that detail item iids are consistent\meaningful and then add all summary items. So then in common Months dlist you'd get 1-12 for months, 13 for "1 Quater", 14 for "2nd Quater" and so on.

That will allow you to use simple time arithmetics in dlist formated items such as calculating previous month by - 1, not by (IF "it was the one after summ" then month_id-2 else month_id - 1) .

Such systems are consistent at the moment of project inception, but as time flows, people change, one or more dlists don't get updated (well, they kinda lay in another lib, are named differently or smth), one or more AT doesn't get there in time and etc.
And in some period of time (rather short) you end up holding a trembling scycraper by rapidly inserting straws. Terrible, ain't it?
This is a common situation in my practice. It's just because it's so easy to build simple things in Analyst that you miss the point where those simple things have formed one of Mandelbrot's set's.
Nowadays, with "we do all in Contributor small interlinked applications" motto it's more than serious. It's hard to find an outdated dlist in Analyst, while digging through macro, but 10 times as hard to debug a sequence of admin links with respect to access tables used.

There are really some ways to avoid these things. There's no 100%-proof recipes, just some common sense.

Let's go step by step, starting from dlist's.

Handling Dlist's

The main Idea: All dlist, forming one dimension should be maintained through one d-cube.
This is very good with hierarchical dimensions, such as products, so we'll use them as example.

Add as much attributes as you need. So if you're gonna do a dlist with not all products for application Z, you just add a column, mark required elements and make it an import link for a dlist.

The sub Idea: All dlist updates and sequencing application updates should be run by a single macro.

So after you create such a dlist for app Z, you add it's @DListUpdate in the UPDATE_ALL_DLISTS_MACRO and add an app Z sync & gtp in there. Therefore -- 1 place to change, 1 button to trigger all changes.

Problems

1) No way to import calc options. Seriously, I don't why it is that hard to do, but you just can't do it (if anybody knows -- drop me a line). So Accounts dimension is hard to handle.
2) No simple way to write formulas. You can write them in text and import Formulae attribute, but adding "{" is annoying.

Some tricks

1) You can use all those DlistItemImport (from cubes, list, odbc's, fm packages) macros instead of import links
2) If you need some sorting, some non-trivial (for Analyst) text operations like spliting\joining strings, adding codes and that stuff -- you can export the cube to a txt file, put an odbc source on it and have a full-blown SQL-92 with CONCAT,SPLIT,LIKE, ORDER and all that nice stuff.
3) You can have a more custom table like

and do all the input in cube, w\o changing the list

2 AT and elists

Main Idea: Have a single source (mentioned above) and do everything automatically.

AT and elists can be (and should be) loaded from csv files.
If you add a column "responsible" in the cube above, and calculate a column with "access level" on base of "responsible" (Yes = Write, No = No Data) -- there you go, start loading the thing up.
3,4 dimensions are okay in a separate AT cube, but it should be a cube, not adding rules in applications. It's just that since you'll have some technical applications, you'll have to repeat those AT's more than once -- and that's a dead-end.
Elist are the same, you can export a dlist as elist since 8.1 and enjoy the result, but I'd rather create all those columns myself.

Tricks
1 Maintaining the same Elist Id allows you to change Display names w\o loosing data, so you can work around that.
2 Play around calculating access level. There was a nice topic on cognoise about automaticaly closing past months. So easy to do with @Time BiF.

3 Manual allocations.

Never. No way to find problem afterwards.

Do a CashFlow Account to P&L Account columns in item descriptions and use them as allocation cubes, use allocation tables when desperate.

I'll add more as I remember, comments welcome.

To get a full budget report we need to do the following:
    1) Publish the whole application
    2) Run the report on published data

Publishing a typical application of 100+ elist takes around 20 minutes, so no real-time here.
But 8.2 introduces trickle publish, allowing to incrementally publish only changed data.  This greatly shortens time spent on publishing.

The question now is how to find out that it's time to run incremental publish.  

By pointing Event Manager on nodestate table we can detect any event (save, submit) happening in application. And using Event Manager ability to detect change in specific column (changetimeid for example) we can fire an event each time somebody saves data. This event triggers incremental publish and there you go.
    1) Somebody saves data in contrbutor
    2) Event Manager raises an event, since nodestate table changed
    3) Event triggers a Contributor Macro running incremental publish
    4) Refreshing a report brings out new data
Since only 1 elist is published at a time, speed is astonishing (around 15s in our case).
Maximum lag between entering data and seeing it in report depends on Event Manager request period (minimum 1 min), so in 2 minutes  max people see entered data in reports.

PS. Event manager requires some condition to start an event and doesn't accept simple "true", "forall" or  something, so we write "1=1" conditions )
PSPS. Disallow cache for appropriate reports to avoid reading old data. Set datasource processing to database only and turn off report cache in query attributes.

Break-Back calculates only on Sum\Substract\Multiply\Division, not on IF-ELSE, or BIFs.
Here are formulas for all 4 operations (4all4 ).
The initial values are marked with index 1 and break-backed by 2. No online latex->png converter I could find, so formulas will be rather ugly.

Addition
x1 + y1 = z1
We need z2
x2 = z2\z1 * x1
y2 = z2\z1 * y1
Therefore:
z2\z1 * x1 + z2\z1 * y1 = z2

Subtraction
x1 - y1 = z1
x2 = x1 + (x1*delta\z1)
y2 = y1 + (y1*delta\z1)
delta = (z2 - z1)*z1\(x1+y1)
Therefore:
x1 + (x1*delta\z1) - y1 + (y1*delta\z1) = z2

So here, the minimum gap is calculated due to initial weights of x1 and y1.

Multiplication
x1*y1 = z1
x2 = sqrt(z2\z1) * x1
y2 = sqrt(z2\z1) * y1
Therefore:
sqrt(z2\z1) * x1 * sqrt(z2\z1) * y1 = z2

If there are 3 arguments x1*y1*a1, then cube root is calculated. So the initial arguments are multiplied by (z2\z1) with 1\n power, where n is number of arguments.

Division
x1\y1=z1
x2 = sqrt(z2\z1)*x1
y2 = sqrt(z1\z2)*y1
Therefore
sqrt(z2\z1)*x1/(sqrt(z1\z2)*y1)=z2

If there is more than one numerator or denominator ( x1\(y1*a1) for example), then after calculating the required value of product, multiplication rules are applied.

Just to remind -- the calculation is defined by order of dimensions, as I've already shown here.

Suppose we need to rename the file test.txt to test_currdate.txt.

On my laptop "echo %date%" gives "05.12.2006".
Be careful, output depends on regional settings (I've got Russian), so you'll need to modify this script.
"test_05.12.2006.txt" doesn't look that good, I'd prefer "test_05122006.txt", so we'll need to calculate 05122006 from 05.12.2006.
This can be done via :~ operator, allowing to cut substrings. Syntax is str:~start_position,length.

So the following line will calculate the variable currdate, holding "05122006".

 
set curdate=%date:~6,4%%date:~3,2%%date:~0,2%
 

rename command allows to change name of file, therefore you just run

 
set curdate=%date:~6,4%%date:~3,2%%date:~0,2%
rename test.txt test_%currdate%.txt
 

Script for grabbing specified files from servers below.

This bat file accepts servernames as arguments and iterates through them to rename&gather all PlanningErrorLog.csv logs in one place (namely, C:\Logs).

 
@echo off
rem Gathering the Logs from command line arguments=servernames
rem directory to write
set destination="C:Logs\"
set user=Admin
set pwd=~~~~~~~~
set log_directory="WindowsTemp\"
set log_name=PlanningErrorLog
echo Monitoring %date% %time%>>c:logsmonitor_log.txt
:LOOP
IF "%1" == "" GOTO END
net use \\%1\c$ %pwd% /USER:%1\%user%set curtime=%date:~6,4%%date:~3,2%%date:~0,2%_%time:~0,2%%time:~3,2%%time:~6,2%
if EXIST \\%1\c$%log_directory%%log_name%.csv rename \\%1\c$\%log_directory%%log_name%.csv %1_%log_name%%curtime%.csv
& xcopy \\%1\c$\%log_directory%%1_%log_name%%curtime%.csv  %destination% /DY
net use /delete \\%1\c$ /Y
SHIFT
GOTO LOOP
:END