探讨一个SAP Dynpro编程的问题: Dynpro切换时，貌似会做隐式数据库Commit，原因何在?

雪候鸟

虽然可以通过其他方法延迟提交增删改的数据，但是为什么不从根本上取消这个隐含的DB Commit? 问了些单位搞了多年ABAP开发的同事居然说没听说过, 难道是我理解错了?

sbtree

不懂SAP的帮顶

adgjl

这是SAP的Standardverhältnis，一个Datenbank-LUW结束的时候自动执行隐式DB Commit，这标志着一个Workprozess的结束。不需要也不要试图取消。

雪候鸟

adgjl 发表于 2012-9-12 23:21
这是SAP的Standardverhältnis，一个Datenbank-LUW结束的时候自动执行隐式DB Commit，这标志着一个Work ...

大部分情况下一套Dynpro序列是完成的一件事情, 如果在每个Dynpro之间切换就发出一个DB Commit, 很容易破坏整个事务的完整性. Workprocess这个概念我也读到过,感觉是个很重量级的资源, 所以需要赶快释放掉. 但是SAP在设计的时候为什么不把这个workprocess搞成轻量级, 其实频繁的DB Commit在一些数据库上容易引发很多性能问题.

sbtree

借贴问一下，SAP中HANA In-Memory Datenbank是什么东东？求给扫盲一下呗

adgjl

你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro到200的时候通过隐式Commit就已经被写入DB了。其实改动不是被立刻执行update的，只是在内存中保存更改的字段，这时候你切换Dynpro根本没有任何DB数据被修改，你可以随意切换Dynpro直到点保存为止，这时候数据改动同步或者异步写入DB。

没有数据更改的情况下，隐式Commit根本不触发DBMS，所以不会引起数据库性能问题。

adgjl

sbtree 发表于 2012-9-12 22:44
借贴问一下，SAP中HANA In-Memory Datenbank是什么东东？求给扫盲一下呗

是个软硬件结合的数据库性能优化技术。说白了就是，硬件上保证把潜在要读的数据提前读到Memory里。对于程序员来说，他的程序基本不变（其实也要针对HANA做一定的改动），本应该从DB读取的数据由SAP从Memory里读出。由于Memory读取速度比DB高N个数量级，所以数据访问会大大加快。

雪候鸟

adgjl 发表于 2012-9-12 23:45
你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro的时候通过隐式Commit就被写 ...

Sollen Datenbankänderungen direkt aus dem Dialogprogramm heraus
(Inline-Änderungen) durchgeführt werden, müssen Sie alle zusammengehörigen
Änderungen auf einen Dialogschritt (i. A. der letzte Dialogschritt) beschränken.
Nur dann ist die Durchführung der Datenbankänderungen als Ganzes (mit dem
Alles-oder-Nichts-Prinzip) gewährleistet.

我当时的理解就是在Bildwechsel的时候会自动提交, 当时还作了一个两个Dynpro切换的实验,发现修改进数据库了. 可能测试的有错误,我回来再看看

雪候鸟

adgjl 发表于 2012-9-12 23:45
你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro到200的时候通过隐式Commit就 ...

如果不是在内存中的修改呢,

如果我在第一个dynpro中执行一个update语句,然后切换到下一个dynpro. 这时候这个update修改的应该会被提交吧

adgjl

你如果Bildwechsel之前执行了Insert，Update之类的当然会被提交。关键在于，你不应该把每个更改都直接提交修改。而应该把所有的改动都在内存中的全局字段中保存，在用户点保存的时候再提交。重要的是你理解SAP的工作方式之后遵循同样的流程编程。