Hi All
We have a new file created, which contains some descriptor and Super Descriptor all in Numeric data type.But when I try to access the file by Read then it always gives me NAT3055-Conversion not Possible error
Could any one have an idea what could be the problem?
Thanks
Regards
Sarabjeet Pal
First, what sort of READ is producing the error; READ PHYSICAL or READ LOGICAL?
If READ LOGICAL, by what field or super?
Is the problem with the READ itself, or the view of the file? If it is the view, what entry in the view is causing the problem?
It is Read logical by Super Descriptor.
The Super Descriptor Consist of 2 field one of N4 and other N10.
We are getting the error in READ statement itself.
Is the error in the first READ, or does it happen in the middle of the file somewhere?
If either case do a READ BY ISN of the file with a view that contains only the two numeric fields of the super.
Do a DISPLAY *ISN field1 (em=h(4)) field2 (em=h(10)).
Look for strange characters in either field. When you get the message, you should know the ISN of the problem record.
Are the two fields descriptors themselves?
How did you load the file initially?
The error is in the first read itself
I will try with Read ISN and check
I just moved value to field of View and Store.
In my view it has MU field inside a PE field-Will that create some problem?
One of the field among them is Descriptor in itself
Assuming the READ BY ISN also fails for the first record; change the view to have only one field in the view. If this fails, you know the field that is causing the problem. If not, it is the other field.
What value did you move? was it something like ‘12’?
I will be back in a couple of hours to see your response.
How many occurrences of the PE group and MU field wiothin the PE are in the view? Try just one of each (or however many you specified when you loaded the file.
Are either of the fields that comprise the super null suppressed, or are they both not null suppressed.
One additional query. Are either of the fields defined as SQL null (NC)?
Read by ISN worked well with 2 field in the View
I have 191 PE field and 6MU in View
No Null Suppression
NAT 3055 say about SQL Null but I am not sure how to check?
I have 1 more question while reading the PE field we should use C* to get the occurance of the filled in values but elemantary field inside PE field are not Null Suppressed- does that means that I will always get 191 occurances.
How can I get the occurance of MU field which is inside PE field as C* needs to referenced as Array to do so right?
Currently I am using OCC and Examine to get rid of the blank values but I think that is not good as we should use C
Could you please let me know how can this be done?
I had the SD key in the View if I remove that and I run- it doesn’t give me that error.I know we don’t need the key in View to be used but never encountered this error earlier -strange:)
First, do you have a STARTING FROM clause with the READ LOGICAL? If so, what have you specified for the value?
Now about occurrences.
When you created the file did you have 191 occurrences in the View? If so, you will always have 191 occurrences, unless, you use the old form of the UPDATE which permits "replacement of all occurrences " by a specified number of occurrences.
Basically, “not null suppressed” means a null value is a valid value; therefore what you will always have (unless old update) is a “high water mark”. Hence, if you create all records with 191 occurrences, C* will always be 191.
I have starting clause having full Key.
Regarding C*- do you mean that if I make the field under PE as Null Suppressed then I would be able to use C* efficiently else it always open up to 191 ?
I have MU field inside PE as Null Suppressed. so I can use C* for this effectively right?
The determining factor for whether a field is null suppressed or not should be whether a null value is meaningful or not. For example, suppose you had a numeric field which was #in-stock (n2). Assume this is to be a descriptor field. If the field is null suppressed, there would be no inverted table for a value of zero. Thus, although you could do a FIND for 1, or 2, or 3… you could not do a FIND for records with zero items in stock. In this case it might well be important to have #in-stock be not null suppressed.
With sub descriptors, the sub takes on the characteristic of the source field for the sub.
With super descriptors, it is a bit more complicated. Suppose I have a superdescriptor with three parts from fields #1, #2, and #3. There is no such thing as a null suppressed (or not null suppressed) superdescriptor. Instead, when a record is added, or updated; and a part of the superdescriptor is null; and, that part comes from a source field that is null suppressed; there will be no entry in the associator for that super.
I will dig up an article from Inside Natural that addresses what happens with C* for MUs and PEs based on the presence or absence of occurrences. I will probably not get to said posting until early next week.
For the NAT3055, check the format of the superdescriptor in the database compared to what your DDM has. If the super is composed of all numeric fields, it is a numeric data element. If the DDM lists it as an alphanumeric field, you will get the NAT3055 when you read the superdescriptor element.
When you remove the SP from the view, it stops including it in the read, so it stops attempting to convert from numeric to alpha.
Thanks Douglas for the Response- I had just checked the View and DDM both is defined as N14.
Okay, I found the article from Inside Natural, and hopefully will be able to attach it.
IN Vol 13 No 2.pdf (786 KB)
The View and DDM are Natural artifacts. You need to confirm what the Adabas FDT has for the superdescriptor format. Run an ADAREP and check the contents of the FDT and its definition of the superdescriptor’s format.