We are having an issue getting GVM's to be accessible to the POSTTRANS.dal script. HAVEGVM is showing the GVM exists, but the values come in blank.
Is an .ini setting that controls this? Does the ordering of the POSTTRANS dal in the AFGJOB matter here?
If the ordering does matter, is there a good way to troubleshoot?
Any help or suggestions regarding this issue are greatly appreciated.
Thanks in advance,
Hi Eric !
My ini files are almost blank and GVM variable loads & unloads properly !!
So, i conclude - if there is any ini setting, it is switched ON by default
The ordering of DALs in the posttrans does matter.
However, i believe, the order of execution of the DALs bottom upwards. Let's say
I have this structure in my afgjob and the order of execution is DAL2, DAL1,DAL3
How are you populating the GVM variables ?
I tried using SetGVM() and received using GVM(). It works good !!
Are you using the rule CreateGlbVar ?
Let me know how are trying to achieve it. I will try in my machine and get back !
The previous response is correct that in a "post" transaction process the rules are running in reverse - from the bottom, up.
The answer might depend upon what is supposed to give your GVM a value. It is possible that it is indeed blank as your script reports. Another thought is that not all GVM types can return a value through DAL. If it is a CHAR_ARRAY, LONG, or DOUBLE, I believe those should work. So the previous question on how your GVM is being created is also relevant.
A few bits of information I probably should have included in my original post...
This is not a straight GENDATA/GENPRINT batch set-up, we are using the WIPEdit plug-in.
The GVM is in the .TRN file that is passed into the plug-in, when the process is ran again to complete the transaction with the data inserted from the plug-in the .TRN file has blank lines where the GVM's used to be.
As far as the way the GVM is set, the below code is used.
The GVM is set with the following command:
curForm = FORMNAME();
Ah. WIPEdit / Entry does not have any access to GVM variables that are generated in Batch. The closest you might get is if the data is mapped into one of the WIP column fields or into hidden fields within the document. Then it could be queried using a method that is available to Entry.
Thanks for that info, that is what I was afraid of.
next question then is...have you ever retrieved data from a field in the letter from the posttrans script? I tried to grab some data using the @("fieldname") and it did not work for me. This was the first method i tried to pass this value before i tried using a GVM.
I am trying to replace the letters date with the current date. Often letters are not "finished" on the date they were created. In order to do a setfld from the posttrans I had to specify the form name in the input string, using a wildcard or leaving it blank did not work.
In the POSTTRANS.DAL
formname() returned a blank value and caused a gendata error
@("fieldname") returned a blank value, no errors
Okay. That probably means that the script did not provide enough information to clarify where to find your field in the document. DAL has the concept of the "current section" and "current field". So, when you call it from a field rule, it would assume that is the current field and the section that owns the field is the current section. When you call it in a Post trans DAL, the system will assign the first section in the document as the "current" section. So, your field is being sought on that section and is failing.
So, you need to provide enough information to locate the field. The @() supports you specifying the section, form, and forms list. The amount you have to specify depends upon what best identifies the specific field you want.
If you know your field is uniquely named in the entire document, you could do something like this:
x = @("FieldName", , , "*");
This says to find the first (and only?) occurrence of the named field within any form list (GRP) specified. That's pretty broad, but you may be able to be more specific.
x = @("FieldName", "Section", "Form", "FormList");
If you specify an asterisk, this means "ANY" within the parent. so x = @("FieldName", , "*") means to find the field within "any" form within the current forms list.
x = @("FieldName", "*") would mean to find the field on any section within the current form (which in this case would be the first form in the transaction).
There may be better examples in the DAL help for the getfld (@) function, so perhaps reviewing that would be better than what I've done here.