Can someone explain why is there a difference between DB link and ODBC Export. Both exporters are omitting several different tables, and the available fields. For example ODBC will export Mass Element Surfaces but it will not include Categories table and Shared parameters in project information table, while DB Link cannot see Mass Surface types.
In order to see the entire database one needs to export twice, through ODBC and via DB link.
I would say that this is a bit inconvenient.
I'm not sure why there are such differences.
But I had a thought........
What if you exported to 3D dwfx and imported into Adesk QTO--would you see the Mass surfaces and the parameters?
That might work, but it does not offer the flexibility of cross-referencing data from multiple sources within the familiar environment like SQL server.
I'm also not sure how to explain the differences between those two tools. I can only say, that as a software developer, we too have struggled to make sure all the various parameters are exposed for our tool, and in many cases it's been unearthed only after a specific request has been made. In other words, it's not all neatly organized in some list, waiting for us to published (though I wish it was).
Here's a screenshot of how we expose the parameters related to Masses. I'd be curious to know if even this would meet your needs? Fields in grey would be editable (in Excel).
Glynnis Patterson, Architect
Linking properties is not an issue, whether done through custom API or using SQL and Forms to work with a database. What, concerns me is the inconsistency between two tools that are created for bridging the gap between an object database and relational one.
For my purpose I am getting what I need, but it would be much nicer to do this in a consistent way.
Access a broad range of knowledge to help get the most out of your products and services.