This happens when a stored procedure dependency changes causing
incompatibilty. In your case it seems there's a procedure (or a trigger,
or a check), which internally executes P_AP_10. Later on, the API (i.e.
parameter list) of P_AP_10 changed, but the procedure/trigger depending
on it hasn't been updated to comply with the new API of P_AP_10.
Upon gbak restore, the procedures are being re-compiled in the database
and this mismatch is detected, preventing the compilation of the
procedure/trigger depending on P_AP_10.
The only thing I can think of is to pass -NODBTRIGGERS and -NO_VALIDITY
parameters to gbak. If the procedure is used by a trigger or a check
condition (which is not a good practice, but who knows), it might help.
If there's another stored procedure, which depends on P_AP_10 and
contains an invalid invocation of it, I don't know any plausible solutions.
Perhaps some specialized gbk manipulation tools (like the surgeon you
tried) would be able to remove a particular procedure from the backup
file, but I don't know about such tool. The gbak output should tell you
which procedure compilation fails (add -V for more verbose output).
Apart from that, you should do your best to repair your customer's
database (find the procedure depending on P_AP_10, update its code and
alter it in the database), because as it is, all his gbak-made backups
are worthless, he won't be able to restore the database from them.