Brian:
An interesting note to this is I use a TCL shell written in BASIC; in
fact, all of our application menus run in BASIC. Consequently, @DATE in
the BASIC subroutine is always the same whenever I run the "SORT..."
from the TCL shell. Run it now, where CurrentTime is defined as (@DATE
* 86400) + @TIME...
2 Dev (0)-> sort SECUSERS BY USERID ID-SUPP USERID ACCTUSER AUTHACCTS
CurrentTime-: 1314093070
...building User array...
CurrentTime-: 1314093070
CurrentTime-: 1314093070
sort SECUSERS BY USERID ID-SUPP USERID ACCTUSER AUTHACCTS 09:51:16 Aug
21 2009 1
UserId......... C. AuthAccts.....................
ASIDBUSER 1 E:\UDAccounts\AsiPublic
E:\DataTrust\Dev
E:\DataTrust\Demo
ASIOFFICE 0
ASIDOTTNET 1 E:\DataTrust\Demo
E:\Advantos\Intel
E:\DataTrust\Dev
3 records listed
...run it 30 seconds later...
2 Dev (0)-> .x
sort SECUSERS BY USERID ID-SUPP USERID ACCTUSER AUTHACCTS
CurrentTime-: 1314093070
CurrentTime-: 1314093070
CurrentTime-: 1314093070
ort SECUSERS BY USERID ID-SUPP USERID ACCTUSER AUTHACCTS 09:51:41 Aug 21
2009 1
UserId......... C. AuthAccts.....................
ASIDBUSER 1 E:\UDAccounts\AsiPublic
E:\DataTrust\Dev
E:\DataTrust\Demo
ASIOFFICE 0
ASIDOTNET 1 E:\DataTrust\Demo
E:\Advantos\Intel
E:\DataTrust\Dev
3 records listed
I have to get back to UniData's real ECL prompt in order to reset @DATE,
otherwise it remains forever. So, it appears that @DATE and @TIME
aren't all that helpful because our entire application stays within
BASIC when running.
Secondly, UniData doesn't have @NI but they do have @ITEM.COUNT. As
noted earlier, there is an inconsistency between the @ITEM.COUNT and the
output of sorted data, in that @ITEM.COUNT only defines the count order
of the initial pass before the sort is performed; thus one has to know
the problem ahead of time and make sure one does a SSELECT first then
the SORT/LIST in order to get the correct order. This is clearly a bug
when relying on @ITEM.COUNT in a dictionary because one never knows how
the field definition will be queried.
Thanks,
Bill
Brian Leach said the following on 8/21/2009 1:50 AM:
No. The point of the post was that the data IS initialized, but then remains
constant until the user logs out (which is what named common is for). He
wants to re-initialize at the start of each listing.
In theory, @DATE and @TIME should not change during a listing (unlike Date()
and Time()). If UDT respects that, you can use this to set a named common
variable that holds the last time the data was initialized:
TIMESTAMP = (@DATE * 86400) + @TIME
IF TIMESTAMP <> MYCOMMONVAR THEN
GOSUB INIT
MYCOMMONVAR = TIMESTAMP
END
Works on UV (where you also have @NI working correctly), I don't have UDT to
hand at this moment.
Brian
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of art
Sent: 21 August 2009 05:59
To: [email protected]
Subject: Re: [U2] UD: Executing small part of subroutine code
once from dictionary call
Bill Haskett wrote:
I have a UD dictionary that calls a subroutine. The subroutine
selects a small file and saves the data into a reformatted array,
which is returned as a passed variable.
I want to only execute this select code once in the
subroutine then
continue with the reset of the subroutines business rule(s) for
subsequent items processed. When I create a "named"
common variable
for the built data array the array is set once and when I alter the
For the named common variable, could you not just use something like:
IF NOT(ASSIGNED(NAMED.VAR)) THEN GOSUB INIT.DATA
Art
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
