The UTF-8 BOM encoding issue that silently drops or corrupts your first data row
After spending time investigating why the first record in a transformation input file was consistently being dropped or flagged as invalid during transaction loading in Oracle Retail Merchandising System (RMS), the root cause turned out to be something surprisingly subtle — a file encoding mismatch.
What is the issue?
When you prepare a .dat file for loading into Oracle Fusion HCM, the file must be encoded as plain UTF-8. However, many text editors and export tools save files as UTF-8 BOM (Byte Order Mark) by default — and this makes all the difference.
A BOM is a special invisible sequence of bytes (EF BB BF in hex) added at the very beginning of the file. The Oracle data conversion tool does not expect these extra bytes, so when it tries to read the first field of the first record, it encounters garbage characters instead of your actual data.
What happens next depends on the data type of your first field:
If the first field is a number → the record is rejected with "INVALID NUMBER".
If the first field is a varchar2 (text) → the junk BOM characters get silently appended to the field value, causing it to fail business validations later.
A real example
Let's say you have adeps1.dat file for loading department data. The first field is DEPT (a number). Your file looks like this in a text editor:1001|MENSWEAR|10|USD|...
# What UTF-8 BOM ACTUALLY saves at the start:
EF BB BF 1001|MENSWEAR|10|USD|...
# The tool reads the first field as:
1001 ← invisible BOM chars + "1001" = NOT a valid number
If your Fusion payroll file is failing to process only the first line, it is likely due to a Byte Order Mark (BOM) or a header formatting error that makes the first record unrecognizable to Oracle HCM.
Open the file in Notepad++ and navigate to View>Encoding, change it from UTF-8 BOM to UTF-8. Submit the UTF-8 file for the file load success.
No comments:
Post a Comment