This small article is to describe a problem with some date property that arises during the creation of an oData entity : one date was generating an "invalid value" error (return code code 500). This was occurring after we filled the return structure, with the correct value.
Description of the problem
We had created an entity with several dates as properties, using an imported DDIC structure. During the test, an error 500 occurred, and when searching in the ERROR_LOG, an "invalid value" for one of the date was found. The value was displayed as DD.MM.AA, on 10 characters.
- A rapid debug session showed that the value that was stored in the return structure of the GET_ENTITYSET methode was correct, and clearly not an invalid value.
- Removing the property from the entity also removed the problem.
- The others dates properties were not problematic,
- Placing the property anywhere in the entity caused the problem. Placement was not the culprit.
Solution
After some test and error we found the problem : the property was mapped to a field of type GBDAT (Geburtsdatum, Birth Date). This component is a date, but also possess a conversion routine. Changing the field to a DATUM (generic date) type corrected the problem...
Well, that's a lie. This did not exactly corrected the problem.
This is because, in the SEGW transaction, the mapping between an oData entiity and a DDIC structure seems to be done at the import time. If you change the structure after the import, the modification are not reported into the mapping. Thus the property was still mapped as a GBDAT and not a DATUM.
We tried to remove the property and re-add it, but it was still mapped to a GBDAT component when we tried to re-import the property. Finally, we had to recreate the entity, and cut'n paste the code for the previous entity in the new. That was the only way we found to generate a new mapping.
No comments:
Post a Comment