Hello, I appreciate getting some clarifying for this situation:
NAT0285: Field reference error; reference invalid or missing.
This error blocks the “update” in Natural One… or not… I´m not sure. I clicked on “continue” and the console shows:
Stowing subprogram '...'...failed
error: NAT0285 Field reference error; reference invalid or missing.
Updating private member of private-mode library '...'...done
The error occurs in GT1.
It seems that this *ISN is not noticed but I´m not sure…
I tried to put another END TRANSACTION right after ST1. but got the same error.
1) I understand for the moment that *ISN is not null because of ST1. Is this correct?
According to the Natural guide provided by my company:
The Natural system variable *ISN contains the Adabas ISN assigned to the new record as a result of the STORE statement execution.
A subsequent reference to *ISN must include the statement number of the related STORE statement.
But what is this “statement number of the related STORE”?
Is it the line number?
If not, how do I reference it?
DEFINE DATA LOCAL
1 BUSINESS-FIELDS VIEW OF FILE1
2 BUSINESS-FLD1
2 BUSINESS-FLD2
2 BUSINESS-FLD3
1 CONTROL-FIELDS VIEW OF FILE1
2 IN-STATUS /* i wish this could be filled by default with the store but it seems impossible
END-DEFINE
...
/* business data filled
...
ST1. STORE BUSINESS-FIELDS
GT1. GET CONTROL-FIELDS *ISN /* the same error occurs with *ISN(ST1.)
MOVE 'I' TO IN-STATUS /* as we don't have a default fill we must do like this, right?
UPDATE(GT1.)
END TRANSACTION
I’m not sure if there is a reason you separated the IN-STATUS field to a separate view or not, but they seem to be on the same file, so can you not just do it as part of the STORE?
Thank you!
Yes, this seems the same situation…
One difference here is that my view doesn’t have fields formatting. I could try this.
( When defining a view its fields doesn’t assume the file’s fields format and size? )
In this case my business fields are recieved by parameters,
and the control fields are managed internally.
Before the STORE I want to prevent duplicate records, with READ or even GET using the same business view , regardless the control fields.
Yes, you can let the format/size default to the DDM values. NaturalONE’s edit function to insert fields from a view always includes the format/size (I’ve asked for an option to omit that).
define data
local
1 BUSINESS-FIELDS VIEW OF NCCONTRACT
2 CONTRACT-ID
2 PRICE
2 DID-CONDITIONS
1 CONTROL-FIELDS VIEW OF NCCONTRACT
2 DATE-RESERVATION
/*) imported data fields from Data Definition Module NCCONTRACT
end-define
contract-id := 123
price := 345.67
DID-CONDITIONS := 'OFF'
*
ST1. STORE BUSINESS-FIELDS
GT1. GET CONTROL-FIELDS *ISN (ST1.)
DATE-RESERVATION := *DATN
UPDATE (GT1.)
END TRANSACTION
END
Same example as before with out the format/size in the local view.
Perhaps you could include a screenshot of the edit area where the error is highlighted - preferably including both the data area and the offending code? This is not a runtime error (NAT0285) - it is a compile time error. Somewhere the Natural parser is not understanding the variables you are supplying.
Man, I can’t explain but today it worked fine.
I wonder if NaturalOne’s compiler got a new clean session or something like this.
I didn’t put format/lenght in the view fields,
I put
ST1. ...
GT1. ... *ISN (ST1.)
MOVE 'I' to IN-STATUS
UPDATE (GT1.)
END TRANSACTION
Error message NAT0166 is telling you exactly what is wrong. All entries within a view must exist in the referenced DDM. If group name BUSINESS-FIELDS does not exist in EXP-FILE, then you can’t use it in EXP-VIEW.
In the following example, BUSINESS-FIELDS and OTHER-FIELDS must be defined as groups in the EXP-FILE DDM.
I appreciate the reply and agree that the error message is pretty straightforward, but as an ordinary programmer I think the documentation lacks some detail and examples.
I checked here and here and it’s not clear that, in this case, grouping must be done in the DDM. Maybe one single phrase could help, something like “using groups in the view require its definition in the DDM”
As far as I knew, redefinition and grouping were different things.
Now I learned that a group is a kind of redefinition, and related to views, it only works in a view if it was defined in the DDM and not in the program.
But I’m learning thanks to this discussion and not the documentation solely.
So I thank you again for your attention.
I wish I could reach the proper “guru perspective” to realize the obviouness in that so simple phrase.
From my “ordinary perspective” one purpose of the documentation is to help the most of people, considering at least different experience levels.
Wether here in this forum, or in the documentation, or even in a source code, it’s all about using language that we hope can be comprehensible for someone else.
The SAMPINT1 code is working with multi-valued fields. If the MU fields are null-suppressed, then what is sent on the STORE/UPDATE may differ from what Adabas will store if there are embedded empty (blank) elements (e.g. “key1”,“”,“key2” will store just 2 occurrences, not 3), so the GET will return the actual MU array that was stored after null suppression is applied. This is rarely necessary - if you can do all your data manipulations before the STORE and avoid the GET/UPDATE steps, you will avoid the 2 extra database calls and improve performance (and clarity of your code).
