I am getting "Null DTExecuteReportOut object returned from provider" while running Drill through report created from Essbase Studio(11.1.2.3).
The report works fine for lower levels but gives this error when trying to pull at higher level like generation 2. In the report, under Advanced Setting I have Acct and Org set at Gen 2 and time and scenario at level 0. All the
hierarchies are recursive.
Also, the users demand to have row governor at 60000 rows. I have changed the server.properties file for it.
Still keep getting this error.Can anyone please help me with this?
Check your logs in:
/u01/EPM/Oracle/Middleware/user_projects/domains/EPMSystem/servers/AnalyticProviderServices0/logs/apsserver.log
You'll see a java exception in there. Basically what's happening is the drill you are running runs an MDX query to build a list of LEAVES that gets passed to your template SQL. When you drill at a level that brings back too many leaves, you get this error (we are on 11.1.2.4.002).
I just spoke with Oracle and they told me the only way to resolve this is to apply patches to Essbase Studio. Here are the patches they are having me apply:
=== Essbase ===
Latest patches
Essbase
27397226 PATCHSET UPDATE: HYPERION ESSBASE SERVER 11.1.2.4.023 (Patch)
27397214 PATCHSET UPDATE: HYPERION ESSBASE RTC 11.1.2.4.023 (Patch)
If needed:
27397220 PATCHSET UPDATE: HYPERION ESSBASE CLIENT 11.1.2.4.023 (Patch) LINUX
27397211 PATCHSET UPDATE: HYPERION ESSBASE CLIENT MSI 11.1.2.4.023 (Patch) WINDOWS
Analytic Provider Services - APS
27397232 PATCHSET UPDATE: HYPERION ANALYTIC PROVIDER SERVICES 11.1.2.4.023 (Patch)
Essbase Studio
25225889 PATCHSET UPDATE: ORACLE ESSBASE STUDIO SERVER 11.1.2.4.016 (Patch)
25225885 PATCHSET UPDATE: ORACLE ESSBASE STUDIO CONSOLE MSI 11.1.2.4.016 (Patch)
Note: After applying the patch and starting the Essbase Studio Server, remember to run the reinit command from the Essbase Studio Command line. This will upgrade the Essbase Studio catalog to be the same version as the server. Also be sure to use the matching Essbase Studio Console version.
Make sure you test this in a QA/DEV environment as the patches may have performance issues associated with them.
Related
I am using on-premise TFS 2015(15.117.27024.0). I created a new root project and wanted to export the Work Item definitions so I can add a few fields that are not in the default layout, as described here
I can export the project config and categories without any issue.
The command I am running(replaced URL with example.com):
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\witadmin" exportwitd /collection:"https://tfs.example.com/tfs" /p:"Library" /n:"Feature" /f:"Library_Feature.xml"
Result:
API resource location 8637ac8b-5eb6-4f90-b3f7-4f2ff576a459 is not registered on https://tfs.example.com/tfs.
I did this several years ago for another project but never had this problem.
Thanks for any help!
I tested on my side, cannot reproduce your issue, everything works as expected.
Whatever you can try below items to narrow down the issue:
Please check if you have specified the correct URL, make sure no any
spelling errors.
Try running the export command on another machine which installed VS.
Try to export the WIT definition file with Process Editor (Power
Tools)
Visual Studio 2015 : Microsoft Visual Studio Team Foundation Server
2015 Power Tools
Visual Studio 2017 : TFS Process Template Editor
You're missing collection name in API request:
Error:
/collection:http://MyServer:8080/
Success:
/collection:http://MyServer:8080/tfs/TeamProjectCollectionName
I am trying to modify my project so that on build it queries for the current TFS changeset for the local directory and uses that to form the build number (using http://florent.clairambault.fr/insert-svn-version-and-build-number-in-your-c-assemblyinfo-file as a reference).
Since we currently are not using team build or any continuous integration for this particular project at this time I plan to use:
tf history . /r /noprompt /stopafter:1 /version:W
However, when I test this command out using the visual studio command prompt in my project's directly (where I work from TFS) it claims:
There is no working folder mapping for xxxxxxxx
The folder is shown as mapped in my workspaces in Visual Studio's Source Control Explorer (shows as the local path), and when I edit my workspace.
Why is the command line utility claiming there is no working folder when it is?
You will see this error message if you are using Visual Studio 2012 (and the corresponding Team Explorer 2012 client) and you are using tf.exe from Team Explorer 2010.
TFS 2010 clients store their local workspace cache in a different location on-disk than TFS 2012 clients. Thus, if you are to create a workspace with a TFS 2012 client, the TFS 2010 client cannot see that workspace data until it has connected to the server and populated its own local client cache.
It sounds like you're okay with using the TFS 2012 version of tf.exe, so I would make sure that your PATH contains an entry to that one first, and this should resolve your problem.
If you really wanted interoperability between the two versions, you would need to make sure to connect to your TFS server from both clients in order to make sure the workspace cache was complete for both. However make sure that you are using only server workspaces in this case, as TFS 2010 cannot connect to a TFS 2012 local workspace.
When attempting to create a new TFS Team Project from VS2012 I received the following error after pressing finish.
TF30279: Plug-in with ID "Microsoft.ProjectCreationWizard.Build" of type "Project Creation Plugins" could not be loaded
TFS and VS were both installed on a Windows 7 laptop for evaluation. When setting up TFS I configured the build server without error.
In attempting to get round the problem I uninstalled all 2012 components VS, TFS and Sql Server, then reinstalled them. I tried both TFS express and VS2012 for web express and full TFS trial and VS2012 premium trial (to rule out that it wasn't an issue with the express versions)
Each time the error would persist across re-installs.
Although I could not find why the problem has occurred I did eventually manage to fix the issue after reading up on process templates and understanding where the plugin models were sourced from.
1) I opened VS2012 command prompt and ran as admin
2) changed dir to %programfiles%\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
3) ran gacutil /i for each dll in the folder that looked like it was anything to do with build.
I'm having trouble getting TFPT.exe to work at all, even after trying to refresh the cached workspace settings per the usual advice on the internet. See below for a log representative of what I've tried and am seeing. Can anyone explain why "tf get" is able to detemine the workspace, but "tfpt annotate" fails?
C:\tfsproj> set tfptcmd="C:\Program Files (x86)\Microsoft Team Foundation Server 2010 Power Tools\TFPT.exe"
C:\tfsproj> set tfcmd="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe"
C:\tfsproj> %tfcmd% workspaces /s:http://tfs:8080/tfs/Apps
Collection: tfs\Apps
Workspace Owner Computer Comment
--------- -------------- -------- ---------------------------------------------
DAVID David_Zarlengo DAVID
C:\tfsproj> %tfcmd% get /preview
C:\tfsproj\src\:
Replacing Readme.txt
C:\tfsproj> %tfptcmd% annotate src\Readme.txt
Unable to determine the workspace
When I edit the workspace in Visual Studio 2010, the "Working folders" grid contains 3 rows, one of which is "Active, $/Foo, C:\tfsproj", therefore, I assume the folder is mapped correctly.
cross-posted on Team Foundation Server – Power Tools & Add-ons
This suggestion from a similar discussion on MSDN forums helped me:
You need to make sure that you are running the commands from a mapped
folder, you can run tf workfold to see if the current folder is mapped
or not (i.e in your case run the commands from C:\Temp)
For those in vs2017: try firing up vs2015 (not 2017), make sure to connect to TFS server in vs2015, and then tfpt worked just fine.
But note: it sounds like the tf powertools commands are being integrated into the new tfs tooling, so tfpt is not really a thing in 2017. See Daniel Mann's answer here for more info and helpful links: tfpt.exe on Visual Studio 2017
I had this same error and the problem was that when I ran tfpt from the command line it was resolving to the 2008 version of the power tools instead of the 2010 version.
Run tfpt with no arguments and in the help it dumps out, it tells you which version it is.
After taking a fresh look at this, it turns out that 'C:\tfsproj' is a directory symbolic link to 'C:\some\nested\path'. Running the TFPT command from the nested path works as expected.
Interestingly, the TFS workspace was mapped to the nested path, so it is surprising that TF commands (e.g. tf get /preview) were able work correctly from the alias path.
I suspect that TFPT does not follow NTFS directory symbolic links correctly when determining the workspace.
As long as you are inside the working directory, tfpt annotate should work. If you are getting the message "Unable to determine the workspace" then it is a caching issue.
If, as you said, you ran tf workspaces /s:serverURL and it still doesn't resolve I would try creating a new workspace and testing it out there. If that works then something wrong with the workspace obviously and I would just delete it and use the new one. If both fail then of course there is a bigger problem but that is how I would approach it.
In my case, here is how I arrived to this problem (error message "Unable to determine the workspace"), and how I solved it.
Arrival:
I had some code. The development moved from the branch in which I worked (lets call it Branch1) to Branch2. I had to continue under Branch2. I shelved the changes, re-mapped my development folder to Branch2, opened Developer Command Prompt for VS2012 and ran the following command
tfpt unshelve /migrate /source:"$/path/Branch1" /target:"$/path/Branch2" "Shelveset Name"
Here I've got the "Unable..." message
Solution:
In my case, the problem was that when I opened command prompt, its working directory was c:\program files\...\...Visual Studio 11.... It worked (migrating shelveset) when I changed working directory to the directory of the Branch itself: c:\MyBranchFolder
I am trying to build a project using TFS2010 Build.TFS resides on its own server, and i am trying to build to a directory on the same machine. The Server does not have VS2010 installed on it.
When the build runs it fails and gives me this error:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1558): Task failed because "AxImp.exe" was not found, or the correct Microsoft Windows SDK is not installed. The task is looking for "AxImp.exe" in the "bin" subdirectory beneath the location specified in the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. You may be able to solve the problem by doing one of the following: 1) Install the Microsoft Windows SDK. 2) Install Visual Studio 2010. 3) Manually set the above registry key to the correct location. 4) Pass the correct location into the "ToolPath" parameter of the task.
Then I get a whole bunch of errors saying the namespaces of the project I am building cannot be found. I am not sure if that is all linked to the above mentioned error however.
Thank You!
It is recommended to have Visual Studio 2010 installed on your build machine but it is not a requirement. Since the error message indicates that it didn't find AxImp.exe, can you verify if this file exists on the build machine? The location is C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin (if you're on a 64-bit Windows).
If the file doesn't exist, installing .NET Framework SDK will probably help to resolve that specific error.
Regarding installing Visual Studio on the build machine, Visual Studio is licensed per user, not per machine, so as long as the build machine owner is licensed, you should not need extra license for Visual Studio. But you probably should look at the licensing papers for your edition of Visual Studio 2010 to make sure.
Here's a table in the white paper on licensing:
You need to have the same software running on the build server as you would if building locally. This means you need Visual Studio 2010, and possibly even the same edition of Visual Studio 2010, depending on what you're trying to build.
IMPORTANT REMINDER: Visual Studio is licensed PER USER. This means that as long as you as a user have a license, you can use that SAME LICENSE on your build Machine.
The only "problem" would be if you actually had "No licenses" - meaning you do not own a copy of Visual Studio at all, but have a legal copy of TFS.