I’m using BO 6.5 and created a derived table, but in my machine it works but in others, the sql of it doesn’t apear and in reports returns an error because the sql produced is only two parentesis and the alias.
Is this happening all on one machine? In other words, as you work on the universe, are you testing it and seeing these problems on your machine? Or is this also happening to the users?
After adding the Derived table, did you export the universe to the repository? If so, did you make sure that the users got the latest version of the universe?
Yes, i exported it to the repository, and the users have the latest version.
Also, i tried to import the universe to edit the universe in another machine and it imported with an error, that had to do with the derived tables, and looking at the derived tables, they had no sql associated, and that’s the same thing with the users reports, they can’t get the sql form the derived tables and just put the parentesis in the query with no sql on it.
Hmmmm, interesting! Open the Derived table in Designer (in edit mode). Is there SQL there? If not, add it in. Then save the universe, export it, and try again. But this time, before the user uses it, have them delete the old copy from their machine, then import a new copy.
When importing the universe in another machine for the designer, the error shown in the importing is connection error, because of not importing the sql from the derived table.
Just interested to know if you ever worked out the problem here as I am experiencing the same thing. Without fixing it or working out what is wrong I am unable to utilise Derived Tables at all which would be a shame.
I believe so. We run very simple 2-tier with a single key file and the ODBC connection defined the same on each PC.
I’ve wondered where the Derived Table definition is stored as it does seem very odd that on a second PC I can see it in the Universe, together with its class and objects but when I try to look at the SQL through “Edit Derived Table” I see no code.
Are you using the same userid on both workstations? i.e. is this not an auth/permissions problem in BO?
DO you also export them in the correct sequence.
yes, whether I use the same user_id or a different one on the second workstation I still cannot see the code.
I’m not too sure what you mean by exporting in the correct sequence but I can sit on PC1 and add a new DT to the Universe and then export it. I then move to the second PC, import the Universe and I can now see the DT itself but not the code that should be in it.
I have wondered whether it is a connection issue and I must admit I don’t think I am totally across where all the connection info is picked up from.
As stated before we have a common key file (does that contain any connection info?) and then the same odbc connections on each PC which have the same user set up in them. I also log into BO with the same usename on the two PCs. Is there something I am perhaps missing here?
Scan/repair has the Scan button greyed out for the universe domain - all other domains scan OK saying nothing to repair.
Then ran “Integrity” against the Universe domain and got “The Universe domain “Universe” is no longer valid. (ADM0003)” which doesn’t sound too good. Error message does not give too many hints as to how to fix it up?
Everything else is working OK so there doesn’t appear to be anything amiss with the Universe. Guess I need to follow up on this one though.
I am running Teradata for both the repository and the user database.
Hi, It was a while ago now but essentially the issue was that in upgrading from 5.1.7 to 6.5 I somehow managed to lose some of the tables of the Universe data model. Once I fixed this up everything was OK. I believe another viewer of the same stream had a similar problem whereby they had created the new Universe tables from a user who had permissions issues ie no-one else (includeing their standard BO users) could see that tables he created and so got the invalid message.
If you follow the URL below you will see another BOBS entry where I more fully documented my problem.