The remote data gateway is optimized for moving data from on-premises to the cloud. If you are moving the data, is there a reason this cannot be written to a cloud source?

This does seem useful.

We were thinking more of a WYSIWYG approach than adding print preview. Although both could be useful. Is this for actual printing or more for export to PDF/image/pptx, etc. 

Export to PDF today is a client-based operation which is dependent on the user’s screen DPI. The users can try adjusting the printing size to find a layout that looks correct with the PDF export. We are working on a improvement to make this easier but it is not yet available.

This capability is on the roadmap.

What would be needed to convert this page to DV project? You can export and print individual visualizations in DV Projects.

Can we get more insight in to the scenario? How many rows can a user realistically read on a page? Or is the main scenario export or are they searching for specific items? Assuming we have to have a limit, what limit would work for your users?

Your usage data may fit on an always free DB instance if the only issue you have is getting an instance. It might be sufficient or could at least help you evaluate how Usage tracking in OAC works and determining your retention needs.

Usage tracking does track activity routed through the RDG. It is conceptually an extension of the connector to a data source. You cloud also evaluate "always free" to get started. https://www.oracle.com/cloud/free/#always-free

Usage tracking does track activity routed through the RDG. It is conceptually an extension of the connector to a data source. You cloud also evaluate "always free" to get started. https://www.oracle.com/cloud/free/#always-free

I see -- you want the cloud service to write to an on-premises DB via the gateway. It is unlikely we will take this approach. The data gateway is very focused on satisfying queries for live analytics and is not intended as a channel for writing. What is the challenge with using a cloud DB? Seems like the real issue is not…

There is usage tracking on OAC -- and the table names are different. Is your question around the schema or specific missing columns/data you are looking for? https://www.ateam-oracle.com/oracle-analytics-cloud-oac-using-usage-tracking…

What default level of logging do you think would be appropriate? Also, how important is each step? 

Understood Philipp. Yes you would still have control. What I mean is that the UI could allow you to match up the columns without regard to order. Of course they would have to be able to be matched as you say -- data types, etc. There just might be two ways to do it... switch the columns around before the union or do it in…

There seem to be two different ideas here. Let me know if this sounds right. 1. Allow unions to work regardless of column order as long as column names match. 2. Allow a way to reorder columns without going to a SQL statement. Let us know if that makes sense.

Would this be okay to enforce only for consumers? That is -- a project author could use them or change them and that is ok?

Can you provide a bit more detail about what you want to see and how you would use the information? You can see query behavior in the console for the data access side of the information.

A few additional questions -- are these set up with Live or Auto query mode? Said another -- is the main issue the UI/Query cache? Additionally, are they looking for continual refresh while the report is being displayed or they just need to be sure it is refreshed when it is loaded? If refreshed continually, if for example…

The overall request makes sense -- a way to navigate to a specific DV canvas via a URL. Is there a way to use a DV project in place of an answers dashboard as a work around? I am wondering if there is a specific reason the user adding them to answers dashboards. 

Is a scheduled task for automation enough or does it need to be an API? I we considering both... but if we had to deliver one then the other, which would you want first?