Hi Joe, we've been using BYODB export for 1.5 year now. At the beginning it was on 7.1 (PU?) and for about a month on v10 (PU24). For us it's working well. We encountered issue in the early days, learning what works and not. But since PU21 it's pretty stable. To highlight what Andrew already said to get better performance and more:- Don't use virtual field. You can use computed field if you need to.- Don't use postLoad() method. Like virtual field, this will force the export to go to staging and that is a major slow down.- Build your own entity : Helps you extract only what you need. Standard entity are not always optimized for export and contains many data source (that you don't necessarily need)- Full push are slow for 2 reasons : The obvious, it push all the data every time. The sneaky one, if your table is big enough (use to happen on table with 2 millions rows), the DELETE command on the BYODB table can take a lot of time. So much that it could make the export time out (1h limit). So we use to truncate the table manually before doing a full push.Andrey, you don't need to delete the project. Just change the default refresh type to "Full push only", when it's completed switch it back to "Incremental".For more info, here's a presentation I made on our experience with BYOD for our chapter :https://www.axug.com/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=59ff18c4-c7f2-af6d-c868-e43f4f0e69f8&forceDialog=0Let us know if you have more questions
Thanks for the clarification, @Steeve Gilbert. I'd hoped we could use TRUNCATE rather than DELETE in DMF. Every little bit of performance helps in that environment!fyi, @Graham Kemp
The accepted approach currently on BYODB is to make a copy of the entity in scope and remove fields not needed in the BYODB in order to lower transmission of data not required.
There are some key things with this approach and it is all around one version. The main one is you are adding code to F&O and of course in adding code there could be an impact in effort when coming to the upgrades on their cycle. However, it does protect you to a certain extent from Microsoft changing their entities to V2, V3 and you having a direct impact from that.
So when coming to look at some data to move to the BYODB the following steps should be considered;
Then there are some general practices you should include
If you've found this thread useful, dive deeper into User Group community content by role