DynamicsAX开发中的各种陷阱（持续更新中。。。）

1. 表单的提交功能。

如果要在表单提交的时候进行内部处理的话，首先要调查清楚这个表单是怎么被调出来的。

如果他的调用者也是表单，那就没有多少风险，如果他的调用者是action,或者是class里动态生成的表单，那么内部处理写在子表单的提交处理里，就很有可能造成事务处理的分隔。

2. prodtable 和 salesline的关系

prodtable和salesline不是1：1的关系，而是n:n的关系。业务上可以先做贩卖明细再做制造，也可以在没有贩卖明细的情况下制造。所以从prodtable里不能通过prodid来找出所有的贩卖明细，而要通过salesid来找。

3. import导致aos服务断掉

import修改过table定义，特别是增删字段的xpo后，特别容易导致aos服务断掉。今天倒掉了3次，惨痛的教训啊。

解决方法是在sqlserver里把相应的table删掉，导入进去后会进行自动同期。

4. Combine XPO的陷阱

combineXPO命令执行的时候，生成的文件路径一定不要指定在源文件的同文件夹内，否则会把除第一个xpo文件外的文件merge2次。

然后会出现warning，提示你同名文件被merge两次。汗的是我merge了两个版本的同名文件，import以后怎么也找不到自己修改的地方。

5.export的陷阱

export的时候如果选中多个文件export，会把他们export到一个文件里，而不是生成各自的文件。

如果你选择的文件中间有间隔，他仍然会把中间未选中的文件全都给你merge到一个文件里。

6.import的陷阱

import的是时候，如果table的字段，或着primary key发生变化了，很容易引起aos服务的中断。

import的时候，如果表里字段参照的edt不存在，那么Import之后，edt属性会自动消失。其实只要你修改或者删除edt，相关的字段的edt属性都会消失。

比如，edt名字要变更的话，把相关src的xpo下载下来替换的时候，会发现edt不存在了。

7. DataSource变量的陷阱

在form的method里，datasource的变量代表当前选中的一行数据。

但是如果你把这个变量在sql文里使用了，比方说作为Jointable的变量写到sql文里，那么里面的数据就不是当前选择的数据，而是变成当前form的第一条数据了。

8. ChangeCompany的陷阱

ChangeCompany的时候，处理中涉及到的record变量一定要先clear后使用。调试的时候发现，如果不clear掉，select执行过后record变量还是保持上一个company的值，

百思不得其解，可能是bug吧，但是clear掉再执行select就没有问题。

9. select的时候

select的时候，如果不把需要的字段都select出来，那么没有取出来的字段默认在record变量里都是缺省值。

也就是说取出来的record变量数据不一致了。。。

尤其是后继调用系统的标准方法，不清楚方法里到底用那些字段，把整个record变量传过去了最后出来匪夷所思的结果。

未完。。。