大家都知道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顺序的先后处理，这样就非常easy发生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-O
把这些信息可视化，dot是一个开源的免费的可视化工具，然后找到循环引用的地方。
假设是procedure的问题，能够升级到HANA SP8，或者转化为同一种object type。