Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 16 Oracle Analytics Lounge
- 216 Oracle Analytics News
- 43 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 79 Oracle Analytics Trainings
- 15 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
"Include Connection Credentials" behavior when exporting/importing workbooks/dataflows
Hello. when exporting a workbook/dataflow/sequence from one instance of OAS (Test) and into another instance (Prod), we always leave the "Include Connection Credentials" option turned off. However, when we import the dva file into another location, it ends up overwriting/replacing the connection information in the target location anyway. I guess I'm not certain what the purpose is of this export feature if it ends up ignoring it anyway on an import and still replaces connection information. Does anyone have any insight into this?
It feels like our best option is to make our production databases accessible to our lower OAS environments, but that's just not very ideal, for reasons that I think are obvious (such ask mitigating security risks).
Regards,
Chad
Answers
-
There is no feature for persistent connections when you use this option. Check if there is already an user connection in the target location to the data sources.
0 -
@Gianni Ceresa Can you please weigh in? Have you experienced this?
0 -
I saw that behaviour, and it was driving me crazy: I have the option to include or exclude something, but whatever I do I have that connection following me and bothering me in the new environment.
That is what killed my trust in the DVA concept overall. That thing is too much of a black box for me, and so far I blamed the reference logic adopted by DV objects with the <name space>.<object name> thing. I would have preferred if everything was more catalog-like: objects have a unique identifier which is their path in the catalog, and that's it. There are no hard dependencies and when exporting it's up to me to pick all I need. And if an object has a dependency and it isn't included in my export, then I should have a simple way to "link" it with the right type of object in the new environment where I import it.
Well, keeping it short, I'm betting a lot on a future development coming that is going to move DV objects in the catalog like everything else (just checked the public roadmap to make sure it wasn't something I wasn't meant to mention).
I expect that with this change, I will be able to use the typical catalog's tools to migrate objects across environments and that will get me out of that DVA thing that I dislike because I have little to no control on it.
All this isn't answering at all @Chad Williams issue. And I also didn't try again recently in OAS 2025 exports/imports of DVAs. But I also had the issue that while saying to not include connection credentials it kept showing up (just because that is a hard requirement to define datasets etc.).
1 -
@Gianni Ceresa Well, I appreciate your response as always, and confirming the behavior I was seeing with this. Hopefully someone can take this feedback and report it back to the product teams for consideration.
In summary, it really just sounds like this feature was not intended for database connections… probably just files or other types of transient sources.
It really does sound like a catalog based approach in the future would be more manageable vs having to rely on the object id's. It would probably challenge to send a dataset over from one environment into another without database connection details, and expect it to latch onto the data connection of the same name in the target environment. Sounds easy in concept, but I don't how practical it is.
I would also just say that don't forget that some people still use Oracle databases for data sources, not just excel, json or other non-persistent data source types. I would hope this is figured into the product, because the old technology isn't going anywhere for us ;)
1 -
@Dhaval Parikh Stantec Doesn't sound like there is anything else to add to this so feel free to close this. Thanks for following up!
1 -
The topic has already been raised with product management. Mostly when trying to define a valid deployment process in an enterprise environment. That's how I had the chance to discuss it a bit with PMs and have a first hint of what was coming with the move of DV objects to the catalog. It was a while ago already, but the development is in progress and I'm optimistic it could be part of OAC Jan 2026 the latest and so make it into OAS 2026.
2 -
Also, I think the workaround/takeaway for us is that we need to have connection objects that need to be fully available and not overwritten vs connection objects that are more volatile and will be overwritten when exporting/importing. Not idea, but sounds reasonable.
So if have a Production Oracle data warehouse called "Prod", this one should never be used for critical high visibility analytics. If I'm doing deployment operation, I need something else called "Prod-Temp" that needs updated credentials after the something is imported from a lower environment.
Thanks,
Chad
2 -
I'm hoping we can get to OAC within the next year. No more server maintenance and patching please :)
0 -
How dare you!! 😯
I love my server, with full access to everything, mostly the BIPLATFORM database schema that let me do all I need without bothering finding an official tool or process :D
But I'm with you for patching and other "boring" tasks.
0 -
Will keep that in mind re: BIPLATFORM. We need that for an audit trail on our reporting. We get requests for usage information all of the time.
0
