Hey there! I notice that when I edit a generic inquiry that is a data source for another GI, depending on the number of edits/saves I need to do sometimes the final GI starts to malfunction. Are there “best practices” for when editing a generic inquiry that is a data source for another generic inquiry?
Solved
Best practices when editing a GI that is linked to another GI?
Best answer by jzhu
Hi
- Always exporting a copy of the original source GI and also the main GI. Especially the main GI, that way if something breaks, I can easily re-import and start refresh.
- I also re-add the source GI to troubleshoot as well. This would give me a clean re-connection as I redo my joins.
- After editing the source GI multiple times, sometimes I also like to reselect some of the fields in my conditions or results grid. From my understanding, this would let the GI reconnect to the fresh column list.
Hope this helps!
Hi
- Always exporting a copy of the original source GI and also the main GI. Especially the main GI, that way if something breaks, I can easily re-import and start refresh.
- I also re-add the source GI to troubleshoot as well. This would give me a clean re-connection as I redo my joins.
- After editing the source GI multiple times, sometimes I also like to reselect some of the fields in my conditions or results grid. From my understanding, this would let the GI reconnect to the fresh column list.
Hope this helps!
+5My biggest worry is causing a cascade of unknown issues on screens I didn’t know were related.
Few recommendations:
- Use a different naming convention in the Inquiry title - i.e. prefix with a standard code to indicate that it’s essentially a subquery (still working on implementing this myself)
- Use the notes on the GI header and results lines to act as code comments
- Create a GI dependency checker by joining GIDesign and GITable on DesignID. GITable.Type=1 will be GI data sources while 0 will be DAC tables
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.