[FGL] FGLSQLDEBUG与FGLGUIDEBUG，除错的好帮手

再厉害的高手也是要靠着不断琢磨自己的 code 才能减少错误的发生。错误不只是低级错误，更多的是思虑上差异造成操作时的认知不同。

Genero 的 DEBUG除错工具位於 GeneroStudio 套件内。但本章节谈论一下不使用除错器怎麽判断大概错误的地方。
Genero编译後形成 p-code，必须透过DVM-fglrun 来执行。因此可以透过外界的干预，例如调整『环境变数』来达到窥探程序执行过程的需求。

fglrun执行的过程中可透过许多环境变数来进行操作干预。例如 FGLGUI(设定客户端样态)、FGLSERVER(设定客户IP)...等，可以查阅 https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_EnvVariables_fgl.html

以下先讨论对於除错相关的 FGLSQLDEBUG 与 FGLGUIDEBUG

FGLSQLDEBUG

预设值 0 可异动范围

• Genero2.50以前： 3 (显示严重错误讯息) 6 (显示重要讯息) 9 (显示细节讯息)
• Genero3.00以後： 1 (显示严重错误讯息) 2 (显示重要讯息) 3 (显示细节讯息) 3以上都一样

也就是说，我们可以透过调整FGLSQLDEBUG的设定，在程序执行过程中查看讯息

export FGLSQLDEBUG=3   

以 Genero 3.20来说，设定後再操作程序，就可以看到『**DVM-fglrun 与 ODI 及数据库讯息交换的过程 **』，包含 4GL内组装的指令样式、经过 ODI 转换後的样式 (因为程序必须以 INFORMIX相容语法来写，所以ODI会有一层转换) ，ODI送到资料库端最後的样式，以及资料库执行结果和回填资料。

例如：

SQL: CONNECT TO "ds+driver='dbmoraB2x',source='t30dev'" AS "ds" USER "***" USING "***"
 | 4gl source      : lib_cl_db.4gl line=594     #程序出现的位置
 | loading driver  : [/u1/gst/3.20.09/fgl32013/dbdrivers/dbmora_11]  #ODI
 | db driver type  : ora
 | ora.c:00859(3)  : Connection parameters for 'ds':
 | ora.c:00860(3)  :  Oracle server    = 't30dev'   #ORACLE或其他资料库连线讯息
 | ora.c:00861(3)  :  Schema           = ''
 | ora.c:00862(3)  :  User name        = '*'
 | ora.c:00863(3)  :  Password         = '*'
SQL: SELECT userenv('SESSIONID') FROM dual          #SQL语句
 | 4gl source      : lib_cl_db.4gl line=796         #code出处
 | ../ODI_common.h:00795(3)  : adaptStatement: stmt type = 1    #ODI转换
 | ../ODI_common.h:00800(3)  : adaptStatement: ifxemul = 1
 | ora.c:01734(3)  : Nat stmt1 = select userenv('SESSIONID') from   dual    #转换成果
 | ora.c:01755(3)  : Preparing SQL (0x278e540): [select userenv('SESSIONID') from   dual]
 | ora.c:01686(3)  : Prefetch rows   = 1
 | ora.c:01693(3)  : Prefetch memory = 0
 | ora.c:03227(3)  : Executing SQL (0x278e540)
 | sqlcode         : 0                               #执行状态
 | curr driver     : ident='dbmora_11'
 | curr connection : ident='ds' (dbspec=[ds+driver='dbmoraB2x',source='t30dev'])
 | into: 1
 |  t:                 DECIMAL(20,0) f:04 v:"35192778"  #执行结果
 | Execution time  :   0 00:00:00.00173                 #花费时间

从上面范例可以清楚理解，透过 FGLSQLDEBUG 能够探知所有的 SQL指令现在运行状态。很有可能实际出错的时候，发生的成因其实是前一个，或前方很远的段落就已经发生选择错误：若用 DEBUG 查询问题时不会很容易抓出实际状况，因此透过 FGLSQLDEBUG 的输出查询会必较容易理解成因。

由於 FGLSQLDEBUG 的讯息量多，因此通常以倒出为档案的方式进行查看，例如透过重导指令：

export FGLSQLDEBUG=3; $FGLRUN test-app > $TEMPDIR/debug.log 2>&1  

将讯息存放到 debug.log 再慢慢查阅即可。

r.h/FGLSQLDEBUG log viewer

程序若能正常运行出结果，接下来需要考虑的就会是执行效能。应该从上面的范例，可以看出FGLSQLDEBUG=3 的时候有包含『SQL执行时间』。因此，不管是 FourJs 或以 FGL 为底层工具开发出的平台，自然都想利用这个数值来对效能旁敲侧击。因此有不同对应的工具，可进行操作

在T100的环境中，可使用 r.h 来执行作业。执行出的 FGLSQLDEBUG log 资料会被收集、统计。将一致的数值收集起来进行平均，就可以取出** 『总执行次数、平均执行时间』 ** 两个指标，接下来评估数值是否合理，要不要透过调整进行优化 (如适当的增加 index 或变换低成本(lower cost)的语法) 就会有比较清晰的答案。

在 FourJs 也在 github 中提供类似工具

FGLSQLDEBUG在处理上更为细致 (因为是FourJS自己的)，能够结合 FGLSOURCEPATH(原始码所在路径) 搭配分析，因此还可以依照 42m module 来进行比序与问题确认。

不管透过 r.h 或 FGLSQLDEBUG log viewer ，都能对开发人理解：程序被操作时的效能，有更清楚的感知。

FGLGUIDEBUG

上方的 FGLSQLDEBUG 在探索 DVM与资料库的关系。而操作的时候，DVM对上客户端软件 (如GDC/GBC/GMA...) 会出问题的，大抵就在网路上了。『封包是否正常的、循序的派送，两端是否保持着连线，License的状况是否支持继续执行，』

这些，在前面的篇章中，曾经提到，都是靠着 AUI TREE变动的讯息封包传递而得来。那麽要除错，就是要观测 DVM是否正确送出封包、客户端是否正确得到封包。

在 [GDC] 基本的概念与操作中能理解到从 Monitor中查看的方法。下面范例看一下 DVM-fglrun 看的方法：

预设值 0 可异动范围 1 (显示传送内容)

export FGLGUIDEBUG=1

基本上，下列的封包讯息并不容易阅读，但是可以拿来查关键字

*** uic_FT_ackFileTransfer.972: id=-1 localName=!!__cached__!!
*** uic_read.578: returns:0
*** uic_read.568: ...
*** uic_readMessage.417: ...
*** uic_readMessage.439: length=138 comp_length=138
*** uic_processMessage.458: FILE_TRANSFER
*** uic_FT_processMessage.1209: id=-2 mtype=GET_REQ
*** uic_FT_processGet.1161: requestedName=16/worksheethidden.png   realName=/u1/t30dev/res/img/ui/16/worksheethidden.png

例如可以探察到资源到底是否送出对的，也可以和 GDC 做比对，以厘清是否在封包的传递上出问题。

善用上述两个变数，可以不用每次都 step by step的操作除错器，对於整体环境的掌控能力会较好，可以多加习练。