震惊！99%的人都不知道的活字格内幕——内建字段的秘密

是谁，让活字格设计器运行时屡屡报错？
是谁，让一位位格友在除错时焦头烂额？

今天，就让我——活字格团队的闪亮新星为大家揭露大家不曾注意过的活字格的细微角落：内建字段与普通字段的区别。


内建字段想必大家不陌生吧，点开一个数据表，永远安安静静躺对象管理器里的四姐妹：创建者、创建日期、最后更新者、最后更新日期。



那么他们就真的如大家看到的那样吗？当然不是！
他们的图标是蓝色的。。。

好吧，其实大家也很清楚，黄色图标的是用户创建的字段，蓝色的是内建字段，同时当大家开启工作流后，还会多出两个字段：状态和担当者。


这六个字段共同记录了活字格内部工作流、用户管理等内容。
那么一定有小伙伴碰到过疑问，我们自己创建的字段能不能和内建字段重名呢？答案是可以的，黄色图标的状态和紫色图标的状态上面的截图图大家也看到了，完全可以共存，这个是没有问题的。在进行一些数据表命令的操作时，我们一样可以通过图标来区分两个字段：


当然命令的正常进行是没有问题的。这是为什么呢？了解数据库的小伙伴应该明白数据库是不允许字段名称重复的吧，那为什么活字格里可以友有两个“状态”，有两个“创建者”呢？
答案就在这里：按住Ctrl+Shift并双击数据表，我们然后看数据表的内容，天呐！这是什么！数据表为什么多了六个字段！





但是仔细看一下，这六个字段，不就对应着数据表里的六个内建字段嘛！比如说，FGC_CreateDate对应创建日期，而FGC_AssignTo对应担当者。

原来，在活字格内部，六个内建字段是用英文储存的，只是为了便于大家理解，在设计器中一般是以中文显示。那么我们透过现象看本质，FGC_CreateDate和创建日期在数据库中确实是两个不同的字段了，所以在使用过程中一般不会因为字段名字与内建字段重复出而问题。

好的，今天的分享到这里就结束了，我是活字格团队的闪亮新星，大家再见！







但是！！！
大家有没有注意到上面的“一般”二字？如果真的就随便把字段名字和内建字段重复的话，在一些情况下是会出大问题的！！

当我们在使用服务端命令的时候，事故就会发生了。一般来说，我们有可能碰到下列两种情况：

情况一：错误覆盖内建字段。

下面我们来看这样一个场景：
小明在库房检查商品的完好状态后，需要对自己在商品表创建中的[状态]字段进行更新，这个字段恰巧和内建字段的[状态]名称相同。小明创建了一条服务端命令：




小明很聪明，意识到了这里需要选择自建字段[状态]而不是内建字段[状态]，小明运行程序，点击按钮，咦？为什么没有反应呢？



小明疑惑地检查数据表，发现FGC_State字段居然变成了“破损”！

怎么回事呢？小明确确实实选择的是黄色图标的自建字段，但是为什么还是修改到了内建字段？

原来，虽然在数据库中他们确实是两个不同的字段，但是在执行服务端命令时，底层的SQL语句其实是使用中文进行查找的，那么问题来了：此时服务器如何判断用户究竟要修改哪个字段呢？服务器无法判断，导致内建字段被错误修改。

情况二：服务端命令运行失败。

前一阵子有一位我们的客户就遇到了这种情况：客户的数据表内容十分复杂，也有[状态]这一自建字段，




在使用服务端命令进行数据更新时，服务端命令甚至没有执行成功，而是出现了人见人恨的500错误！
当数据较为复杂时，服务器的计算很有可能因为字段的名称相同而导致无法计算，最终产生命令回滚，发生错误。


当然，还很可能有情况三、情况四……因为活字格底层的机制很复杂，我们无法预料名称相同还会出现什么错误，如果真的因为名称重复又出现了其他不可预知的错误，活字格的工作人员们也真的很难解决这种奇奇怪怪的错误
总结一下，根据无数人惨痛的除错教训，大家一定不要让自建字段和内建字段名称重复！！！


p.s.有时候我们也会使用外联数据库，为了避免本贴这种情况的出现，不知道大家有没有注意到一个细节？




外联库在初次连接活字格的时候，默认是不允许更改的，此时也不会有内建字段；只有勾选表设置中的[允许活字格修改数据库或表结构]，才会生成6个内建字段。因此，在我们不需要修改外联库，同时外联库很有可能命名与内建字段重复的时候，这个复选框建议大家不要勾选，这样也就避免了本贴这种情况发生。
希望本贴可以让大家少走弯路，除错时少掉头发~

你这个有标题党的嫌疑啊

hzg还有多少内幕

lh123 发表于 2021-3-2 20:46
最后一张图，太搞笑了。

lh123 发表于 2021-3-2 20:46
最后一张图，太搞笑了。