Has anyone experienced this? It is very frustrating as I have spent several hours preparing workbooks in the upgraded 9.2 version. I try to publish to the 9.1 Tableau Server, but it will not allow it. Looks like I may have to spend several more hours recreating the dashboard on 9.0 again (9.0 is compatible with the Tableau Server we have, but 9.2 is not).
Can someone please help :(
Thank you,
P
Here's a little hack that works.
Unpack/unzip the .twbx file if you have a .twbx file, to get the .twb file. (To unpackage/unzip: Change the file extension from .twbx to .zip and unzip how you would normally any .zip file. On OSX, double-clicking the .zip file in Finder unzips it and displays the separated .twb and .tde files).
Open the .twb file in a text editor.
Towards the top, you will see a line like this
<workbook source-platform='win' version='9.1' xml:base='http://bi.teslamotors.com' xmlns:user='http://www.tableausoftware.com/xml/user'>
Change the version='9.2' (which is the Tableau Desktop version you saved the .twb file in) to the version compatible with the server, eg. version='9.1'. Open the file in the Tableau Desktop version you just switched the text to, eg. Tableau Desktop 9.1 in this case. (Tableau allows installing multiple concurrent versions on the same machine).
You should now be able to publish your dashboard to the Tableau Server.
Note that this is indeed a hack to save hours of re-doing the same work again (since there's no easy copy-paste in Tableau!), and is of course recommended to follow the official way that the other posters have suggested.
Source 1, Source 2
Tableau is not backward compatible .
This is applicable for both Desktop and Server .
Workbooks created in newer version would not open in previous version of the software. Also, same way it will not be able to publish to prior version of the server .
You might need to recreate everything, or you can upgrade your server .
Major and minor releases Workbook Compatibility after Upgrading
Tableau Desktop
Workbooks and extracts that are saved in a later version of Desktop
are upgraded and cannot be opened by any earlier versions. Exception:
A version 8.3 workbook can be opened in Desktop 8.2. For example, a
version 9.1 workbook is upgraded when saved in Desktop 9.2. The
workbook can no longer be opened by Desktop 9.1. Workbooks and
extracts that are opened but not saved in a later version of Desktop
remain accessible by the earlier versions they were created with.
Workbooks created with the latest version of Desktop can connect to
earlier versions of Server beginning with Server 8.0. For example, a
workbook in Desktop 9.2 can connect to Tableau Server 8.2 or 8.3.
However, a workbook in Desktop 8.1 cannot connect to Tableau Server
7.0. Workbooks created in a later version of Tableau Desktop cannot be published to earlier versions of Tableau Server. Exception: Workbooks
created with Desktop 8.3 can be published to Tableau Server 8.2. For
example, workbooks created in Desktop 9.2 cannot be published to
Tableau Server 9.1. Workbooks and data sources downloaded from earlier
versions of Tableau Server can be opened by the latest version of
Desktop.
Official Doc here
As a rule, update your Server version prior to Desktop. For example, if you have Server version 9.1 it will only accept the current and prior Desktop versions 9.1, 9.0, etc. Always keep your Desktop version at or behind your Server version to keep it all compatible. As mentioned, the easiest fix now is to upgrade your server to 9.2 if possible. Good luck.
As a rule, major releases (9.0, 9.1, 9.2, etc.) are not backwards compatible. I highly recommend upgrading your desktop and server versions at the same time, and always do the server first. This way, you don't run into the issue of the server not being able to read what you are creating in desktop.
For resolving the backward compatibility issues, you can always use to below mentioned link to convert your Tableau workbooks to any version from Tableau 8.2 to Tableau 9.3
Tableau File Conversion Utility
Hope this helps you out.
Related
How do I download MySQL “Connector/J 5.1.48” platform-independent on macOS Mojave? There is a project I’m working on and I need this specific connector to work on my computer because there’s a specific Android Studio related project I need it for. When I try downloading it, I get an error message. Just in case it’s not possible, are there any other database replacement options that work well with Android Studio that are simple to implement on macOS?
Link to Connector/J 5.1.48: https://dev.mysql.com/downloads/connector/j/5.1.html
Thanks.
JAR files already are platform independent... They are not executable
I'm not sure how your error is specific to Android Studio, but mobile apps should not be directly querying a Mysql database, but rather reaching a web API that exposes database results over HTTP
And even if you did want to use mysql drivers in an Android app, you'd add those with Gradle, not JARs
That being said, MacOS isn't the issue either, and there's plenty of database replacements for Mysql
I have been using the Big Query browser interface on Chrome on my Ubuntu 10.04 machine for a couple of years. Within the last couple of weeks the https://bigquery.cloud.google.com page would no longer load fully. I get a mostly blank screen with only the "COMPOSE QUERY" button and links to Query History and Job History, but no datasets or tables are visible. I am able to load the browser interface fine on my Windows 7 professional machine. The version of Chrome on the Ubuntu machine is 27.0.1453.93. I know this is an old version of Chrome, but updates are no longer available on my version of Ubuntu.
Here is a screenshot of what I see on Ubuntu....
That's an unsupported version of Chrome (or more likely -- Chromium, if it was installed from the standard repositories).
You should be able to install a more recent version from the following link, although I'm not certain that support goes back to 10.4:
https://www.google.com/chrome/browser/desktop/
I'd also strongly encourage you to upgrade to a more recent version of Ubuntu -- 10.4 LTS hit end-of-life earlier this year and I don't believe it is receiving any further security updates.
See:
http://www.ubuntu.com/info/release-end-of-life
I would like to find out from fellow developers if there are any pitfalls in using a recent libmysql.dll with a previous MySQL server. I use Delphi with DbExpress to build database applications.
My main reason is that I have both Delphi 7 and Delphi 2010 on my development machine. I have built applications with D7 that use MySQL 5.0 but D2010 requires MySQL 5.1.
I would like to avoid upgrading all my previous DB applications if I can help it hence would like to keep using MySQL 5.0 server but still develop all new DB applications using D2010.
Your advice and or suggestions on this matter will be highly appreciated.
I had similar, with D7 and D2010 apps, and suggest you look at it the other way round - move to MySQL 5.1 or later and test your D7 apps to confirm they work.
(If they don't, add newer version of libmysql.dll (e.g. for MySQL v5.1.8), and make SURE you are not using the "old" libmysql in the windows path (rename all other files and put the new libmysql in your app exe directory.
HTH
Chris
I just read something about HTML 5 Web SQL Databases. I did a little search on here and Google but couldn't find a simple to the point answer.
Can someone tell me, where is the data stored when using this? In memory or a text file or something else?
Also what browsers support this?
Web SQL locations by system for Google Chrome:
Windows Vista or 7
\Users\_username_\AppData\Local\Google\Chrome\User Data\Default\databases
Windows XP
\Documents and Settings\_username_\Local Settings\Application Data\Google\Chrome\User Data\Default\databases
Mac OS X
~/Library/Application Support/Google/Chrome/Default/databases
Linux
~/.config/google-chrome/Default/databases
It's stored in a SQLite database. Here is a browser support chart I found: .
That said, the W3C has officially dropped support for WebSQL in favor of IndexedDB. Here's the equivalent chart for that:
You may also want to look at DataJS, which is a library that abstracts some of the details of local storage and works across browsers:
Hope that helps.
Here is one browser example:
On Windows 7, Chrome stores Web SQL (aka SQLite) databases in:
C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\databases
Each extension or website that uses Web SQL is given its own folder. Within each folder will be a numbered, extensionless file that is an SQLite database. You could open said file with SQLite Database Browser or any SQLite-supported application.
And in case anyone is looking for IndexedDB:
On Mac OS X:
Chrome
~/Library/Application\ Support/Google/Chrome/Default/IndexedDB/<site>.blob (Blob storage)
~/Library/Application\ Support/Google/Chrome/Default/IndexedDB/<site>.leveldb (everything else - just LevelDB)
Firefox
~/Library/Application Support/Firefox/Profiles/<profile>/storage/default/<site>/idb
I have the following strange situation here I need some help with:
I am building a Qt application with MySQL access. For this I have:
- a dedicated building machine, using Qt 2010.05 and a MySQL 5.1 just for the libraries, Windows 7 32 bit. This machine creates the install package.
- a dedicated development machine, CentOS 5.5
- two testing machines:
- - an "always" fresh install of Windows 7
- - another Windows 7 machine with a newer Qt on it used for other stuff too.
I have built the previous version of the application sometime in February this year (on the bilding machine), it works nicely and perfectly, loads the MySQL driver (I have put it in the sqldrivers directory as indicated by everyone else). The install package installs, works everywhere (at least on all my Windows machines).
Now, I have built another release of the application, on the same machine. In the install package the only important difference is the executable (and some HTML files, but those are not relevant). Everything else is the same. When I run the NEW executable on the build machine I get ("QSQLITE", "QMYSQL3", "QMYSQL", "QODBC3", "QODBC") as the QSqlDatabase::drivers() output. If I run the NEW exectuable on any other machine I get an empty list of drivers. If I run the OLD package on any machine it works...
The loaded modules by the two processess (old executable, new executable) are basically the same, except is the qtmysql DLL which gets loaded in the old one and not in the new.
Have you ever encountered a situation like this? If yes do you have a feasible solution for it?
Thanks,
f.
Qt will only load plugins which are compatible with the program or version of Qt used. See the Deploying Plugins document.
You could also try using QPluginLoader to manually load a plugin and check what is reported as the QPluginLoader::errorString when it doesn't load (add the error message to your question if you can't fix it still).