大家都知道SAP HANA项目打包成Delivery Unit(缩写为DU)。按照“官方”的开发模式，特别是整个团队只使用一个HANA Instance进行项目开发，由于HANA本身还在不断成长中，会遇到各种奇葩问题导致打包出来的DU在新环境中import 失败。那些失败Error Message trace,对于开发者基本上没什么帮助。
而且在项目开发过程中，总会有些队友会不按常理出牌，最终导致项目DU无法使用，特别是在测试资源匮乏的情况下，很多问题不能及时暴露。当你看到满屏幕的错误，你还有信心和耐力分析下去哇？看HANA Trace？你知道怎么设置么？
在这里整理一些常见问题来给大家一些启发。
View(视图)的建立不加depends_on_xx
问题分析：
在使用hdbview时，有些伙伴们习惯把在console中query语句直接黏贴到hdbview中完成了事。而且这样的hdbview在单独Activate时，毫无问题都可以Activate成功。而导出的DU想往新环境中部署就出问题。
在单独创建时，所有引用的table、view都已经存在，Activate肯定成功。而且在开发过程，基本上不会遇到先后关系，你引用的永远是存在的table、view。比如下面的例子我们称它为viewA，那么viewA-> com.sap.test.tables::02_HDB_DEPARTMENT_VIEW。而在DU导入过程中HANA会进行优化处理，对objects进行Activate顺序的先后处理，这样就很容易发生viewA先与com.sap.test.tables::02_HDB_DEPARTMENT_VIEW创建。DU导入失败，如果整个项目中view都没有加dependence信息，那就满眼的Error，请问如何下手。而且修改了一处，根本不解决问题，看不出效果。很多人就此放弃分析…
解决方案：
schema="MYSCHEMA"; query="SELECT * FROM "MYSCHEMA"."com.sap.test.tables::02_HDB_DEPARTMENT_VIEW""; depends_on_view=["com.sap.test.tables::02_HDB_DEPARTMENT_VIEW"];
创建、修改hdbview必须检查depends_on_view和depends_on_table。可以写个python脚本去检查或跟新这些代码，在每个伙伴提交代码前都运行一次。或者就依靠CI环境快速反馈问题，拖的时间越久越难分析。
使用Calculation View用call却不用select
问题分析：
创建Calculation View，一般在Activate后会在_SYS_BIC下生成一个package/viewname/proc这样一个procedure。很多“用心研究”的伙伴发现都发现这个procedure，如果在另外一个Calculation View直接call这个procedure写起代码更简单，并且他自己新创建的这个Calculation View，Activate完全没有问题，开心的不得了，还把这个新发现分享给其他同仁。
结果打包出来的DU又一次嗝屁了。问题原因同上，Calculation View没有显示的写出dependency的信息，HANA自身会根据你object的代码分析出来Calculation View A依赖于Calculation View B，前提是你得按游戏规则出牌，你得用select Calculation View B with parameters
解决方案：
vals = SELECT * FROM "_SYS_BIC"."mytest/cv_test_filtergroupid"(placeholder."$$In_Filter_Group_ID$$"=>:In_Filter_Group_ID);
Calculation View的使用必须用Select
the circle dependence(循环引用)问题
问题现象：
在Activate All或者导入DU时，出现循环引用。
在HANA中循环引用分两种
1． Object 自身的循环引用
A->B->C->A，这样的循环发生的情况比较少，但不代表没有。
2． Object Type间的循环引用
这个情况发生在procedure和hdbprocedure中，比如procA –> hdbprocB -> procC，这样就会出现循环引用。
解决方案：
dot -Tpdf <file_name> -O
把这些信息可视化，dot是一个开源的免费的可视化工具，然后找到循环引用的地方。
如果是procedure的问题，可以升级到HANA SP8，或者转化为同一种object type。