DDRTDTD的专栏

当用session.createobject 创建BO时候，要给域hs_stateflow 和hs_state 赋值。怎么找到这2个值呢？2种方法。1.如果此bo在用户数据库中已有创建的记录，直接到用户数据库里面找就行了。2如果此bo在用户数据库里面没有记录，那么要到 hs_bf_sdb数据库里面.先找hs_stateflow的值，再找hs_state的值。找到hs_statefl

可以肯定的一点，报错了，需要查看日志的报错信息。记录下某次纠错的信息：designer崩溃后，查看报错信息，报了一个如下的错：。。。。。。。。。。。。。。。。。。。。。。。。。。。。SELECT a.hs_modified_time, a.f_db_type, a.f_db_name, a.hs_uuid, a.hs_created_time, a.f_db_password, a

现象：在前台停掉 UDB后，在designer中升级 USERDB，升级进度条走到底，看似升级成功，但是刷新下，版本又降下去了。遇到这个问题。。。 buddy, you are so unlucky。。。。如果这个在生产环境上出现了，就不要做处理了，让甲方联系原厂吧，毕竟自己搞弄坏了就不好了。如果是在自己的开发环境或者是不重要的环境，可以通过数据库的还原来重新升级下。如果你升级

eg 状态uuid 为A ,怎样通过UUID在数据库里面获取 状态的中文名称呢？在hs_locale表里面。f_item_id 的前36位 = UUID A , f_text即为中文  select left(st.f_item_id,36) as stateuuid , st.f_text from hs_locale AS st  WHERE st.f_locale_name='zh_

从这个SQL 中可以 快速定位到xml中的脚本的地方。 仔细分析下就知道了。但是这个sql 不能查any 状态下的transition 。 查询方式：select   hs_uuid,f_value  from hs_text_blob where f_value  like .......查出的f_value   栏位就是脚本代码。然后就是扩充下这个sql，可以快速定位到xm

如果是global scripts  还好点。找到 userdb  里面的 hs_global_script 表的f_script 栏位，存放的就是 全局脚本。如果是 transition 的代码或者  can ,before，after 里面的代码，在designer中就没法搜索了，得去数据库查。找到 userdb的hs_text_blob表， 搜索 f_value 栏位，看代码大概能够

这张表记录了userdb里面的BO 和对应的表。主要有以下几个字段 f_visible_flag , f_editable_flag ,f_is_sfo,f_name ,f_table_name 首先 f_name 对应的是BO的名称，f_table_name 对应的是 数据库的tablenamef_visible_flag  为 0 表示designer 一般模式下不可见，工

查找sfo 的UUID (不是查找sfo的实例的UUID)select f_root_oid from hs_stateflow_object where f_bo_name =( select f_root_oid from hs_business_object where f_name='DT')DT 为sfo/bo 面板（即 stateflow object properties面板

升级失败的原因可以从 Hansky\HBP\Server\nt-service\stderr.log 中看出来。这个得能够分析出日志报的错误。（很多情况下失败报java.lang.OutOfMemoryError 的错误，估计是内存不够，把启动参数内存值设置得大点，不过还是得看你的物理内存有多大了，这时候改jsl.ini文件，将-Xmx 参数调得大些，1024M-1400m） 现在

此问题 遇到过一次， 再次重启HBP服务之后，发现正常。查看报错日志，记录情况如下： 初步看了下是mysql 的问题，连接被拒绝。 14:59:20  jetty重启后面是报错 14:59:20.553 EVENT  Started org.mortbay.jetty.Server@1835282java.sql.SQLException: Communicatio

1. 能够支持的单个solution版本最大是多少？（以单个solution导出xml的大小为衡量单位）         solution支持大小主要跟系统环境有关，目前我们使用的solution最大的有到200M+      2.对于现有的solution，单个版本导出有100M，是否有办法将solution 拆分（比如拆分到不同的solution里面）？（有些 sfo和bo等有

所有的表都有hs_is_deleted 列表明这条记录是否有效(1为无效) 但是似乎hds数据库的hds_user 表 有个delete_flag 字段似乎替代了hs_is_deleted这个字段，默认好像这张表hs_is_deleted字段都是0的。另 t_action_log 表 的hs_is_deleted 字段不起作用，t_sfo_change 表也是如此。先讲下hds数据库：hd

hs_lov 表记录了所有的LIST OF VALUE 。这张表就不多说了。 hs_option 表记录了 所有的 LIST OF VALUE 里面的option ，用 hs_lov.f_root_oid  = hs_option.f_lov_id  ,hs_option.f_display_name = 你需要的那个option的显示文本值，定位到唯一的记录。hs_option 表的f_

没必要每张表都介绍，只讲下比较重要的几张表t_action_log1.表 t_action_log 记录了操作 sfo 或者bo 时的日志，从t_action_log.hs_foreign_oid 关联到BO或者sfo 的 id，  t_action_log.f_transition_id 关联到 sfo或者bo 的transition ，其他的字段一看便知，没啥好说的。 hs_a

需要查询库，故查询的是部署版本，而非在designer中的未部署版本。 省去了 transition太多，每次都需要在designer内打开transition面板操作的麻烦。 Stateflow的 transition  查询SQL ( 其中 fromstate或 tostate为空的应该是 any节点的 transition) 数据库 是orac