I am using tableau server - 9.1.1 (9100.15.1013.2200) 64-bit. When I upload workbooks the tooltip is showing incorrect values (i.e. they are not the same as that in the workbook i have on my system). Why would that happen?
Is it because something is wrong with my workbook?
This is a known bug in tableau server that has been fixed in 9.1.3 and successive versions. I faced the same issue and I usually single-click on the relevant chart and the tooltip updates to show correct information.
This is the answer I got from folks over at Tableau:
"It turns out that this particular issue was considered a high risk to the existing code to implement the fix. The code changes that were made in 9.1 made this fix less risky and so the developers were able to implement the resolution in 9.1.3. 9.2.2, and later versions.
The issue was reported by a handful of users, about 5 others, due to the high risk in the 9.0 branch if something went wrong it could potentially affect hundreds or thousands of users (you included). The decision was made in favor of the fix being implemented in 9.1 and 9.2."
Related
I am having some recent problems with TFS 2018 that have escaped my ability to troubleshoot. The application runs on a Hyper-V VM hosting Server 2019 and connects to a separate MS SQL 2016 database over on a separate Windows 2019 VM.
A few weeks ago we migrated our database server over to a new machine which, over the course of setting our existing TFS server up to use the new database, required us to run though the TFS setup wizard again.
Everything was fine for about a week when we started to have issues, specifically with the TFS web front-end we use. First we lost various icons on the webpage, with the browsers (Chrome, Firefox, etc). replacing them with rectangles:
A little while after that we lost our project Dashboards, and the whole dashboard page is just blank now. A little while after that, our WIP build/test automation feature also lost its management section of the site.
Other than these things not displaying, things generally "work" - the source control stuff functions, work items can be interacted with, etc. It's just that the interface is clumsier without the icons (which extends to every icon within every work item type, not just the banner I shared) and we can't get our automated test reports without the site's front-end for it. The latter is the real show stopper.
I spent some time troubleshooting and at best was able to figure out a maybe solution for the icon problem: https://social.msdn.microsoft.com/Forums/en-US/c1038468-9d94-473d-a020-254789e9a19b/tfs-2015-update-2-missing-icons?forum=tfsgeneral
This seemed to do the trick for just the icon problem, though some time later they disappeared and reappeared when people were refreshing pages. I'm still unsure if the re-failure was a fluke or not, as we rolled back the VM snapshot the changes were made on shortly after.
Using Chrome's developer tools, it seems like the lack of dashboard data is related to issues retrieving content on the host server for a cause we cannot determine.
Here is what shows up on the DevTool in Chrome for our main project's Dashboard:
What's interesting is the error claims widget.css is either not present or empty. Neither of these are the case as I can find the file and read data in it.
I recognize MIME types as a thing that shows up in IIS but I don't know what to do with the information. Should I be adding .css to the MIME Types list within IIS? Maybe that was set and the wizard reverted it?
Here's what shows up in the Builds section:
Thing is, I don't know what to do with this information. I found some vague hints online from people having similar issues with sites they were themselves coding (which stated the errors in question were red herrings), but this TFS front end is not something I've created and I had not any idea what to do with the information shared.
Does anyone have an idea of what might have gone wrong with the dashboards here? I have run out of ideas and can't figure out a different attack angle to approach this from.
I'm an Business Intelligence Developer. I'm developing for/maintaining a Microsoft BI Solution at our Company (SSIS,SSAS etc.). Recently I updated my Visual Studio to 2019 Enterprise (before that I was on 2015 Enterprise). Integration Services Extension Version 3.4. (also tested 3.2). With VS2015 everything was fine..
Part of our Data Warehouse is data coming from an PostgreSQL DB. I'm connecting to this using the official Postgres ODBC-Driver (32Bit, Unicode). I tried version 10.01 (old one, worked with VS15 without issues) and 12.01 (current one).
The Issue is the following: I opened the package I have the issues with. It warns me that the PSQL-ODBC-Datasource needs new metadata (nothing changed there nonetheless..). I can run the (unchanged) Package without any issues! Then I double-click the Source. A dialog pops up if I want to correct the Metadata of the Source according to the db it points to. Then the warning disappears. But If I run the package now it fails instantly telling me that the Source I just updated needs new Metadata.
I tracked the issue down to a minimal example. If I get data from a timestamp-column on the PSQL-ODBC-Datasource I allways get, immediately after execution of the package, an VS_NEEDSNEWMETADATA-Error in Visual Studio (SSIS) and the package won't run. There is no yellow Exclamation-Mark on the Source like it is usual. Everything seems fine on design time. I can even preview the output of the source in it's properties. If I select another column instead of the timestamp-column there is no issue. If I select the timestamp-column again it again gives the error on runtime. I also tried different Postgres servers with different versions as Source and different ODBC-Drivers.
If I set ValidateExternalMetadat to False on the source everything is running fine, but this can't be the solution as it worked flawlessly previous.
It seems like SSIS-Packages created with Visual Studio 2019 can't retrieve timestamp-columns from PSQL-ODBC-Sources if ValidateExternalMetadata is enabled.. This is driving me nuts!
Did anyone have this issue and find a solution?
Greetings
Edit: Further Investigation: It seems like VS2019 translates a PostgreSQL Timestamp now to dbTimeStamp2 instead of dbTimeStamp (like 2015 did) on the Output-Columns. But the Metadata also stored in the Package-Xml seems like it's telling that the columns are dbTimeStamp. This mismatch seems to be the Core-Issue why the Package is telling the the Metadata needs to be updated!?
OK I ran into the same problem here and it drove me crazy. I have the same setup and I got the exact same error messages.
Unfortunately I have no solution for this problem but at least I can tell you that it doesn't seem to be a isolated issue as I'm affected as well.
I overcame the problem for the time being by disabeling ValidateExternalMetadata but thats not a setup for production environments.
Thanks for this post though. I helped me not to feel like an idiot again. :D
Cheers
Daniel
Be careful with the casing. I had a view (as data source) in development, with two columns in uppercase.
Before creating the view in production, I decided to change to lowercase both columns, just because all was in lowercase and that two columns were the only things in uppercase. Then I created the view.
My ETL ran fine in DEV, but it didn't in PROD. Finally, I realized that the difference in casing was the problem.
When I changed the view in PROD, so that it was the same as in DEV, it worked smoothly.
I have installed MySQL Workbench (v 6.3.9) on my mac macOS Sierra 10.12.4.
There are several problems with displays.
I do not have access to export options in "Forward Engineer SQL Script", there is no text in the catalog in the left panel (and more...).
What can I do to workaround these problems?
You're correct, MYSQL Workbench (v 6.3.9) is buggy, though it is still possible to do Forward Engineer through Database->Synchronize Model. An alternative to viewing the text in the catalog is clicking the layers option on the right to display your tables.
Cheers!
Every software has bugs, it's just sometimes less obvious (here however very). No doubt, both are serious problems. The first one is already known and we will fix it for the next release. The second problem however is surprising. I just tried the version available from the MySQL website and the catalog tree shows fine for me. Would be good if you could create a bug report for that, so we can fix that too.
We are trying to publish a data source from a Tableau desktop version to tableau online and especially to synchronize the extraction, to have it run every 15mn.
We've managed to do only once.
Since that, we tried to publish other datasource and get them synchronized and every time, we faced the same error.
Tableau Data Engine Error: 10000: Path does not exist.
Parsing Tableau's KB, we found the same issue here but without any silver bullet...
We've tried the following
Uninstall Tableau desktop
Delete the remaining folders
reboot the machine, on which Tableau is installed
reinstall Tableau desktop
Did all the publishing again
Not sure what else I can do...
Any tips are more than welcomed.
If it needs to be precised, we are doing the extract from a postgres database through tableau desktop.
Thanks.
My colleague figured out the answer.
On Tableau Desktop, you can use date as parameters on the SQL query.
However when you are trying to publish them on Tableau Online, the data source has some kind of glitch and is looking for something that it should not be looking, therefore creating the bug.
Putting the date in static with a date that goes back to 1980 with a filter, solve the issue.
I have a problem with the CrystalReportsViewer's toolbar that puzzles me. Let's say I have a report that consists of five pages.
If I click the next button, I get to page two as expected, but if I press it again, page two reloads!
I can click the last page button and get to the last page, but if I try to go to the previous page from there, I end up on page one again.
So, no matter how many pages my report has, I can only get to the first, the second and the last one!
These problems began when we migrated from Windows Server 2003 to 2008. We're running Crystal Reports 10 which perhaps have problems under 2008? Can any of 2008's new security stuff be responsible for this?
Has anyone seen this behaviour before and know how to solve it? Thanks!
Never seen that Dev tool before so it won't be in our supported platforms.
I recall something similar and it was due to the screen resolution or zoom level.
Have a look at the source code of the page to see what it is doing. Compare it to a VS .NET ASP.NET app to see what the differences are.
I haven't seen this weird behavior before, but I know from a project I worked on a few months ago that Crystal Reports isn't supported on Win2k8 / IIS7 yet. I wish I could find a link that stated that for you, but I remember running into that problem.
I had to go the route of setting up a virtual server to host Win2k3, just so I could publish some reports.
Oops, it seems this isn't considered programming related (even though there's been a certain amount of programming to show the reports and that the CrystalReportViewer is a server control), so sorry about that.
Thanks Ken for your input. I bet i doesn't help that we're running an old version of CR as well. Maybe your route with the virtual 2003 machine is the best to go.