#Tableau Cloud69 utenti parlano di questo argomento

@DIEGO FERNANDO MARTINEZ RODRIGUEZ

Hi Diego, thanks very much for the detailed reply, especially the explanation of why embedded data sources are slower. That matches Tableau's own documentation about the extract being written on the Tableau Cloud server rather than on the Bridge client, and it explains the error we're seeing perfectly.

Going through your checklist -- we'd already covered most of it, and tested your two new suggestions today:

a. Bridge client shows Connected, pool status Ready.

b. The Redshift hostname is in the Private Network Allowlist and mapped to our Bridge pool. Good tip on the IP, we hadn't tried that. Our hostname resolves to a private IP via a VPC endpoint, so we added that IP to the allowlist as well, mapped to the same pool. Refresh still failed with the identical error:

This server violates the ip allowlist/blocklist restrictionsUnable to connect to the Amazon Redshift server "<our-cluster>.<our-region>.redshift.amazonaws.com"

c. Verified outbound 80/443 from the Bridge client to Tableau Cloud, all open and working. Our Bridge client runs on Linux so the Service mode point doesn't apply to us.

d. We created a published data source via Explore > New > Data Source and it connected to Redshift successfully, which confirms Bridge itself is working end to end.

e, f, g. Edited the workbook connection to the correct hostname, deleted and recreated all schedules, ran a refresh. Same failure.

So we agree published data sources are the right answer. Where we're genuinely stuck is getting our existing workbooks onto them, and I'd really value your view on three things:

1. Our workbook has two embedded data sources. One of them can't be published separately at all — Tableau Desktop greys out the option with "Data sources with calculations that reference other data sources must be embedded." Is there a way around that, or does it mean this workbook is permanently locked to embedded data sources?
2. Repointing an existing workbook to a published data source is a Replace Data Source operation, which per the docs is Tableau Desktop only. Our Redshift cluster is private-only and resolves to an internal IP through a VPC endpoint, so Desktop on our laptops can't reach it at all. Is running Tableau Desktop on a VM inside the VPC the normal approach here, or is there a cleaner pattern we're missing?
3. Our workbook is 63 MB, over the 50 MB web upload limit, so uploading through the web UI isn't an option either.
4. One more thing, our Bridge client runs on Linux (in a container) rather than Windows. Does the embedded data source limitation behave any differently on Linux Bridge, or is it identical? And since Tableau Desktop doesn't run on Linux, does that mean anyone using Linux Bridge necessarily needs a separate Windows or Mac machine inside the network for the publishing step? Wondering if there's a Linux-friendly workflow we're not aware of, or whether Linux Bridge deployments just accept that constraint.

We have 10+ dashboards to migrate and they need to stay exactly as they are since they're business-facing, so rebuilding from scratch isn't viable. Any guidance on the right pattern would be hugely appreciated. 

Happy to mark this as the accepted answer once we've got a working solution, just want to make sure the thread lands on something that actually resolves it, in case anyone else hits the same wall.  

Thanks again for taking the time to reply.

You can do the Union in your first Custom SQL script itself as shown below 

SELECT A,B,C 

FROM XYZ 

WHERE Condition1  

UNION ALL 

SELECT A,B,C 

FROM XYZ 

WHERE Condition2 

UNION ALL 

SELECT A,B,C 

FROM XYZ 

WHERE Condition3  

 The crosstab export only pulls data from a single worksheet's grid — those text sheets you added as visual headers have no data behind them, so they don't make it into the export. 

What works is putting the header text into the actual data sheet as a calculated field. Something like: 

'Main Header Name' 

Drop it on Rows above your dimensions, same for the sub-headers. Then they're part of the data structure and will export. 

If you need merged cells or visual formatting though, the export won't preserve that — you'd have to format in Excel after. 

@Nicole Chang

From what I see the LWC component does not have a checkbox to enable the oda (on demand access) access or to pass the oda groups claim.  These JWT claims are needed so you can give access to the ODA access:

You may confirm with Salesforce support creating a case: 

Take into account ODA (On demand access) is only available for Tableau Cloud tenants with Usage Based Licensing or the newly introduced Capacity Based Licensing 

If this post resolves the question, would you be so kind to "Accept this Answer"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you. 

Regards, 

Diego Martinez 

Tableau Visionary and Tableau Ambassador

@Himal Singh

If you want to embed without authentication and keep data in Tableau Cloud, this site may help you. 

But each viewer needs a Tableau Cloud license. 

If you want truly public access with no license, Tableau Public is better.

 @Rajashekar Atmakuri

As Mr.Diego mentioned, it would be helpful if you could share the exact error message first, but here are a few possible reasons why this might be happening:  

As explained in the documentation below, when you change the owner of a workbook on Tableau Cloud, the embedded credentials used to connect to the data source are cleared/lost. This could be causing the data source connection to fail.   

If this is the case, you should be able to resolve the issue by editing the data source connection and re-embedding the credentials (the Oracle ID and password).  

While this might be less likely, if you are using two or more Oracle databases located on different networks, you will need to set up a dedicated Tableau Bridge server for each network/pool.  

Hi @Wiwit Setyaningsih

I'll reiterate both yours and @Gohar Clients thoughts on the compute by - definitely on the right track. Here's where I can take things by working on that and a small tweak and additional calc: Workbook re-attached.

First thing you'll see is a new calc: YoY (Latest Year  Only)

IF LAST()=0THEN [YoY]END

(NB: I also renamed your "Calculation 3" to YoY). 

The new calc just says "only return a value for the last year* in the view". We do have to tell Tableau that we care about the year for this part of the calc. And what we end up with is a nested table calc where the compute by for one part is different to the other! 

Right click and edit the table calculation pill on Rows:

First up I'm working on the "Latest Year Only" calc as you can see in the top drop down. And I tell it to compute by specific dimensions and year only. So the latest year should be the last (LAST()=0) in the window. 

Now I change the drop down to the "YoY" calc and tell this to compute by specific dimensions again, but this time Year and Month (in that order)

NB: Show calculation assistance is quite handy here as I can check that I am indeed seeing values 13-24 in the window. Now you might be thinking "hang on, how did my lookup -1 work in that case?!?"  and you'd be right! I also changed the lookup to be a lookup by -12 so now we're looking back to the month 12 months ago. 

The lack of an ELSE in the second calc is what supresses the previous year from showing ... it's still available to the calc as we've "filtered" using a table calc so that happens late in the order of operations ... and those are the "nulls" shown by the >12 nulls indicator. 

Finally I CTRL+click and drag the pill from Rows onto Mark Text too so that I don't need to repeat the nested compute by there. 

Let me know if this helps!  

Compute by is often fiendish enough without (a) nesting; and (b) your great workaround for side-by-side without a discreet pill on Columns! 

Ta, Steve