I'm guessing that by "blow up" you mean "identify and remove"?
The fact that idxbuild & dbrpr don't find anything to object to is a case of good news and bad news.... The good news is that nothing is wrong at that level. The bad news is that finding the bogus data is going to be hard. The other bad news is that dumping and loading isn't going to change anything about that data.
Since there doesn't seem to be any actual corruption (from a dbrpr POV) it seems more likely that somehow bad data was actually entered.
Tangent:
In my misspent youth (before Progress) I once worked with a system (I didn't write it! Honest.) that didn't filter input very well. At one point I had to cleanup the data because a new user got the idea that she could change data in fields by using the arrow keys rather than tabbing & back tabbing to get to the desired fields. This resulted in some spectacularly messed up data... Not all that dissimilar from what you're seeing.
I mentioned code pages as one particular example of a class of problems. It is not the only way that inappropriate data can get into a field. However... the characters that you showed sure look like
someone has the wrong codepage set. Code pages are not just server parameters -- they can also be set for the session and it is possible that your terminal emulator is using something incompatible as well. It may just be a single user who has been messing around with settings that they don't really understand.
Or it could just be someone using copy & paste in a peculiar way.
In the original post you show the "Dep Code" field as having bad data. It looks like a character field (even though it seems to only hold a numeric account number, for now I won't lecture on that topic...) If that is correct then you could, perhaps, identify the data with something like this:
Code:
for each department no-lock where dep-code > "~~":
display dep-code.
end.
(I'm assuming that the table name is "department" and the field is "dep-code".)
The assumption here is that whatever caused the bad data to be entered only acted on these "department" records. I don't know if that is the case or not.
(Also, the error messages that you shared would not seem to have anything to do with this problem.)