In a NSC report i’ve found the line X := DATABASE.USERID; I’ve found no documentation about the function DATABSE, and it seems to be no difference whether i use “DATABASE.USERID” or simply “USERID”. What’s the purpose of “DATABASE” and which syntax does it have ? thanks in advance Stefan Weinreich Billing Analyst
Hi Stefan There is no difference at all, look under DATABASE in the symbol menu to see the database functions. Paul Baxter
In this case, the DATABASE context prefix was not really required, but the FILE context prefix must sometimes be used explicitly in objects with an implicit record variable (Rec). In these cases the compiler (correctly) reports type errors if you code COPY(‘c:\foo.txt’, ‘c:\baz.txt’), since it interprets COPY as Rec.COPY. The same applies to FILE.RENAME vs. Rec.RENAME. Kind regards, Jan Hoek Weha Automatisering BV Woerden - The Netherlands
Hi Jan is right, there is also the case when your table includes the field USERID. In this case is would be the record value that would be used and not the database value. So you would use DATABASE.USERID. i.e. IF rec.USERID=DATABASE.USERID THEN … In this case USERID is the same as rec.USERID. Paul Baxter
that means, that whenever i use a database-variable like USERID, TODAY and so on and there is a field in a used table that has the same name i need to use DATABSE to make sure the report uses the correct value ? If there is a table with the fields “linenumber”, “userid” and “today” and i read a record of this table i need to use DATABSE.userid or DATABSE.today to make sure to get the value of the database (current user or current date) instead the value of the same named field ? Stefan Weinreich Billing Analyst
Thats right, Also you need to be careful if you use the WITH command as well. Paul Baxter
quote:
Originally posted by StefanWeinreich: (…) I need to use DATABSE.userid or DATABSE.today to make sure to get the value of the database (current user or current date) (…)
TODAY is a member of the SYSTEM context; use SYSTEM.TODAY . Kind regards, Jan Hoek Weha Automatisering BV Woerden - The Netherlands
Going slightly off topic you sometimes have to use rec.VAR or rec.PROC(). We had an instance where a developer had a test on an onvalidate trigger on a table. He also defined a variable for the same table to test existing records and then he used a WITH with the Variable. When he called a subroutine from within the WITH section things did not work as expected. When he traced through the code he noticed that his global variables zeroed when the procedure was called. What was happening was the procedure was called on the instance of the table as defined by the variable and not the base table so putting rec.proc() solved it. The moral of this story is never use global variables and pass all parameters to procedures. Paul Baxter
I once saw an instance of Rec.Action creating a conflict with the ACTION context in an Advanced Distribution object. Rec.Action was set as an option field as well, and trying to call ACTION::LookupOk resulted in a compiler error. How would one get by this problem? (BTW, I have reported it to my NTR as a bug grin). Regards! Kristopher Webb Kelar Corporation, Canada
I once saw an instance of Rec.Action creating a conflict with the ACTION context in an Advanced Distribution object. Rec.Action was set as an option field as well, and trying to call ACTION::LookupOk resulted in a compiler error. How would one get by this problem? (BTW, I have reported it to my NTR as a bug grin). Regards! Kristopher Webb Kelar Corporation, Canada