I have a need to access a ready-only copy of the AX business database that is sync'd in real time. We can then sync this database to our own azure sql database for reporting purposes.
Comments
Yes, please make this happen. Azure SQL already natively supports this capability, but we currently aren't allowed to access it.
More info here: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview
"Active geo-replication enables you to configure up to four readable secondary databases in the same or different data center locations (regions). "
"Because the secondary databases are readable, they can be used to offload read-only workloads such as reporting jobs"
Category: Reporting and Analytics
Yes please, can we please have this. We have been asking Microsoft product team for this in more than a year, so thank you for starting this site. On top I would like to add the need to run all reporting on the read only copy as well.
Ulrik
Category: Reporting and Analytics
We really need this feature, because in the current situation we have to export a lot of data to BYODB.
The "BYODB-Process" costs a lot of development time and also the customer has to pay extra money for the additional Azure SQL to analyse his own data.
So please make it happen!
Category: Reporting and Analytics
This is the one of the biggest ask from clients and giving it out as read only would speed up implementations and adoption of BI tools to the fullest. Thanks for even considering !!!
Category: Reporting and Analytics
We did investigate using the BYODB option but found the following short comings.
- Ideally, we are seeking a solution that does not require building of a data mart / data warehouse.
- It is difficult to achieve a snapshot of data that will provides data consistency between AX and the BYODB. To acheive this, we need to synchronize data across multiple data entities.
- Some data entities require a full export. When reporting directly from the data entity's staging table, there is a point in time where there are duplicate transactions therefore we had to export and join to the DataManagementExecutionJobDetailStaging table to eliminate dirty reads. This is may lead to performance issues down the road as this table becomes very large.
- When there are export issues, it impacts the users when they are reporting off the staging tables. To mitigate this risk, we would have to build an number of extra processes.
- In order for our views to be performant, we need to add indexes to the staging table. This impacts the data export process. In some cases the delete step of the process fails (due to query timeout) leaving records in the staging table. When we are replicating data every 5 to 10 minutes, this can leave millions of duplicate rows in the staging table.
- We need all exports to support incremental exports. There are some cases where the framework forces the entity to a full export because there is a view used as the root data source.
Category: Reporting and Analytics
Administrator on 7/30/2019 3:41:40 PM
We are looking into adding more data into Azure Data Lake including the option to add Entities and key tables.