This error is a likely indicator of data corruption in the database.
Internally HVR uses UTF8 to exchange data and hence there should be no data that cannot be transferred. As a result HVR will translate every string it finds in the database into a UTF8 string. HVR identifies character encoding in the database and will take encoding into consideration when the translation happens. The error “F_JG2901: UNKNOWN string ” containing invalid sequence encountered while encoding table ” column ”” (with values for the indicators in angle brackets) in indicates that somehow a string could not be translated into a valid UTF8 string.
To get around this error you can use the action TableProperties /IgnoreCoerceError. This action will ignore the error and simply put in a valid character (like an upside-down question mark) for whichever character did not translate into a UTF8 string. This means that the actual data changes, but given it is invalid data to begin with this may be much better than having the replication fail.
You may however want to do some root cause analysis when you run into a problem like this. I have seen this a few times on an Oracle Database. A couple of ways I have used in the past to find offending/corrupted data are:
- Export (e.g. using expdp) the data and import it again. This has in some cases exposed the corrupted data.
- Perform computations on the corrupted data when the data was numeric. This gave very weird results (e.g. 10x a positive number resulted in a negative amount); note that the error for this corruption was invalid target numeric size i.e. a different error than in this question.
Of course when the corrupted data has been identified you can go back to the application/users to fix the data.