Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

CONNECT EAP

TABLE OF CONTENTS

Virtual tables

Save PDF
Save selected topicSave selected topic and subtopicsSave all topics
Share
Share to emailCopy topic URL
  • Last UpdatedSep 03, 2026
  • 2 minute read

Virtual Virtual tables enable integration between CONNECT and the third-party analytics platforms, such as Snowflake and Databricks.

Virtual tables allow you to:

  • Access operations data for analytics initiatives.

  • Support the integration of operations data into existing business and financial data infrastructures for data exploration, reporting, and analytics.

  • Make Data views available on-demand to third-party data and analytics platforms as an external data source.

Your third-party cloud analytics platforms will be able to interact with data from CONNECT using the native languages and tools you are familiar with.

You can share your CONNECT data in three ways:

  • Databricks: Requires a Databricks metastore ID to create a share.

  • Snowflake: When you create a share, CONNECT provides a qualified share name, bearer token, and Iceberg endpoint for use in Snowflake catalog configuration.

  • OpenSharing: An open, tool-agnostic share that you can use with any Delta Sharing-compatible platform or client, such as Power BI, Spark, and Pandas.

For information about data access and permissions in Databricks, read the Databricks documentation.

Current limitations

  • Virtual tables partially support community data. The initial creation of a virtual table and subsequent scheduled refreshes of the virtual table will successfully complete. However, any updates made to data in a time range prior to the current refresh interval will not be automatically captured in the virtual table. To capture any changes that have occurred in the past, perform a manual refresh of a set time range of data.

  • Virtual tables are derived from data stores, which includes data streams and entities. Event store data is not yet supported.

  • CONNECT does not have user-facing system logs for virtual tables.

  • Service state and metadata are backed up. In the case of catastrophic failure, services are restored and re-materialization of virtual tables automatically occurs upon recovery.

    Contact AVEVA customer support for resolution.

  • Virtual tables currently support timestamps with a maximum precision of microseconds. For more information, see Create a virtual table.

Update processor

In the event that there are stream data changes that affect a virtual table with an interpolated retrieval mode, all intervals for the virtual table between the nearest predecessor and successor events will update at the next refresh. If the nearest predecessor to the data change is more than one month prior, we will limit the value to one month prior to the data change. For example, if a virtual table has a sheduled refresh of every 2 months, when a data change occurs, you will see updated data for within a one-month window.

If additional previous events need to be updated, you can perform a manual refresh for the time range needed.

Virtual tables workflow

  1. If you have none available, create Data views.

  2. Create a share to connect CONNECT to your third-party analytics program.

  3. Create a virtual table using your data views and share.

  4. Manage permissions for virtual tables if you need to add new roles or adjust existing roles. For more information on roles, see Roles.

In This Topic