Circular Reference

[CoN73mP7]

Hi,

I#m trying to read in a csv file with the TI but I've got a problem with my time dimension.

This dimension is defined by the columns year,month,day,hour,minute and second.

I've defined the first 5 columns as Consolidated and the 'seconds'-Column as the Element. But I always get an error while reading in my data which says something like circular reference. Could anybody please help me how to do this?

Alex

[Alan Kirk]

I#m trying to read in a csv file with the TI but I've got a problem with my time dimension.

This dimension is defined by the columns year,month,day,hour,minute and second.

I've defined the first 5 columns as Consolidated and the 'seconds'-Column as the Element. But I always get an error while reading in my data which says something like circular reference. Could anybody please help me how to do this?

It would be useful to know the exact message, and more importantly to see the code in which the error is occurring.

[CoN73mP7]

Hi,

"25208880","2011-01-02 22:22:08","2011","1","2","22","22","8","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4327","4","327","1","$Revision: 1717 $",Zeile 3 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209260","2011-01-02 23:01:06","2011","1","2","23","1","6","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","5445","5","445","1","$Revision: 1717 $",Zeile 39 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209265","2011-01-02 23:02:11","2011","1","2","23","2","11","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4874","4","874","1","$Revision: 1717 $",Zeile 40 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209510","2011-01-02 23:22:40","2011","1","2","23","22","40","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4182","4","182","1","$Revision: 1717 $",Zeile 59 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209515","2011-01-02 23:23:44","2011","1","2","23","23","44","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4203","4","203","1","$Revision: 1717 $",Zeile 60 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209985","2011-01-03 00:00:22","2011","1","3","0","0","22","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4705","4","705","1","$Revision: 1717 $",Zeile 94 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209990","2011-01-03 00:01:30","2011","1","3","0","1","30","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","8112","8","112","1","$Revision: 1717 $",Zeile 95 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25209995","2011-01-03 00:02:35","2011","1","3","0","2","35","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","5203","5","203","1","$Revision: 1717 $",Zeile 96 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25210000","2011-01-03 00:03:40","2011","1","3","0","3","40","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","5288","5","288","1","$Revision: 1717 $",Zeile 97 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.
"25210240","2011-01-03 00:23:04","2011","1","3","0","23","4","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","5043","5","43","1","$Revision: 1717 $",Zeile 115 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.

This is my errorlog. The data where the errors happen are already included in the errorlog so you get an idea what the data looks like

[Alan Kirk]

Hi,

"25208880","2011-01-02 22:22:08","2011","1","2","22","22","8","_no_user__","0","0","_no_jobtyp","_no_jobsta","BJS_ADM","package.job","BatchJobServer","startNewJobs","DML","DML: Select","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","SELECT * ","---","SELECT * FROM V_Job_After_Processing ORDER BY JAP_Sort FOR READ ONLY","4327","4","327","1","$Revision: 1717 $",Zeile 3 in Eingabedatei MetaData Vorgangszeile (40): Eine zirkuläre Referenz wurde beim Kompilieren der Dimension "TC_Zeit" entdeckt.

This is my errorlog. The data where the errors happen are already included in the errorlog so you get an idea what the data looks like

Perhaps, but what we still don't know is what line 40 of your metadata tab looks like, or indeed what the code in the rest of the tab does.

However I can make an educated guess.

When you say that you have:

defined the first 5 columns as Consolidated and the 'seconds'-Column as the Element.

what are the exact names that you're using for the elements and consolidations? My suspicion is that you may be defining (say) "8" as an element name for the second but also trying to define it as (say) a consolidation name for the minute. You may well be doing the same thing with (for example) "22". So at some point you're probably saying something along the lines of "make 8 (meaning the second) the child of 22 (meaning the minute)" but on some other line you may be saying "make 22 (meaning the second) the child of 8 (meaning the minute)".

These are just examples, it doesn't have to be those specific numbers. The point is that you're probably telling TM1 that A is a child of B on one line, and that B is a child of A on another. You may mean "A the second" in the first case and "A the minute" in the second one, but TI has no way of knowing that unless you use unique names to identify them.

[CoN73mP7]

Thanks, that was helpful. Your guess was completly right! I've added an describing name to the Elements and now it's working. But it seems to me, that this shouldn't be necessary because TM1 should know which of the Elements are under another Element and which aren't.

[CoN73mP7]

Now that I've got this working, I tried my TI Process with a more data than till now. My problem now is, that although my datafile is 200000 lines long, he stops working after about 110000 lines. The process ends without errors. Anyone a idea why this could happen? It's not a problem of the data.

[Steve Rowe]

Hi Con,
Re your first point all element names in a dimension have to be unique there's no "positional" logic that says it's OK to name an N level the same as a C level.

On your second point, how do you know that only 110k lines are being processed?

My best guess of an answer is that you need to do an accumulating load. A TI will naturally overwrite values in a cell rather than add values to a cell, so if you have some kind of count measure in the cube you are loading to then you won't get the right answer.

You first need to retrieve the value from the cube, add it to the value in the file and then write the result back.

200k row is no problem for TM1.

Cheers,

[Martin Ryan]

How do you know it only does 110,000 lines? One way to check is to do a counter. In the prolog put counter=0; in the data tab put counter=counter+1; in the epilog put asciioutput('C:\myfile.txt', numbertostring(counter));

In general the asciioutput (or it's cousin textoutput) can be a useful way of error checking. But bear in mind that if you write to the same file in the prolog and data tab then the prolog file will get overwritten by the data tab file, so it's a good idea to export to a different file in each tab.

Martin

[CoN73mP7]

I know the exact number of lines because each line has a data value of 1 so the sum of all entries in the cube gives me the number of lines processed in the TI-Process.

There is no possiblity that the values can overwrite other values, because each of them is unique by a time dimension

And I know that TM1 can at least manage 64 mio. of datas because I've seen a test wich did just that

[Alan Kirk]

I know the exact number of lines because each line has a data value of 1 so the sum of all entries in the cube gives me the number of lines processed in the TI-Process.

I beg to differ; that's an assumption, not a certainty. Believe me, we've all been there plenty of times where we've assumed that one thing is being written, but upon tracing exactly what the code is doing we find that something quite different is being written.

There is no possiblity that the values can overwrite other values, because each of them is unique by a time dimension

That's assuming that the data source is correctly showing all of the unique time dimension values. If it turns out that some of the lines have (or use) the same element value you'll just be writing 1 over 1 and never knowing the difference.

Martin's suggestion is the right one; use a counter variable and output information to a text file via AsciiOutput to see exactly how many rows are being processed. If it's the full file (which I have a suspicion that it will turn out to be since as you know there's no problem with TI handling a file that size) then the next step will be to trace the values and see whether it's attempting to write 1 to a cell which already has a 1 value.

Finally, don't forget to check the MESSAGE log of the server to see whether there are any messages like "process terminated because of stack overflow".

[CoN73mP7]

That's assuming that the data source is correctly showing all of the unique time dimension values. If it turns out that some of the lines have (or use) the same element value you'll just be writing 1 over 1 and never knowing the difference.

I've written a java test to test this. There is no same element value in my time dimension. But to make shure of this I've connected a unique ID with my time dimension.

I'll try your tipp with the counter but while the TI-Process is working, there is a little window showing the progress of the load an I can see that it stops each task shortly between 107k and 109k (because the window refreshs just every second)

Edit: So I've tried the counter and it told me as expected, that the metadata as well as the data part of the process are done 109936 times.

[lotsaram]

So what record is at row 109936 of your data source? Do any of the fields contain non-printable ASCII characters that TI might be interpreting as a file terminator?

[nish]

Thanks, that was helpful. Your guess was completly right! I've added an describing name to the Elements and now it's working. But it seems to me, that this shouldn't be necessary because TM1 should know which of the Elements are under another Element and which aren't.

To: CoN73mP7: can you please explain what you mean by "adding describing name to the Elements"? I have the same problem, where I have a Consolidation element 'Year' and my date_key at the simple element level is a number. So I'm getting this error 'a circular reference was detected compiling dimension'.
Thanks in advance!

[qml]

Hi nish, welcome to the forum. The user you've asked for help hasn't logged on since roughly the time Occupy Wall Street began, Bin Laden and Gaddafi were still alive, South Sudan was still in Sudan and Lady Gaga was topping all charts. This sort of thread necromancy rarely gives desired results. It's usually better to read the Request for assistance guidelines and then start your own thread, giving as much detail as you can about your problem.

[CoN73mP7]

@qml: That's right. I just got notified about a reply here so I thought I'd have a look.

@nish: Hi, I'm sorry, but I won't be of any help with your problem, because the last time I've "worked" with TM1 was in 2011 and I have no idea, what this thread was really about.

Alex