You have probably deleted the default category and the code tried to use it unconditionally. Now it should work but issues belonging to the deleted category will no longer have a category.

I've confirmed that I've deleted the default category (General with id 1) and that is causing the problem.
Problem solved by adding a new category and changing the id to 1.
ISSUE 0014478 has some extra info and prevents users from deleting the default category.

issues belonging to the deleted category will no longer have a category.

The code should not permit that, i.e. prevent category deletion unless $g_allow_no_category = ON;

Furthermore, IMO the code should fallback to $g_default_category_for_moves, not to an empty category (as Mantis does not allow that category to be deleted, see 0014478)

I can delete a category with issues attached to it and the issues will end up with "(No Category)" as category.

I've verified that:
General category got id = 1.
$g_allow_no_category = OFF;
$g_default_category_for_moves = 1;
The issues are connected to a project with category_id set to 1.

So, the fallback to $g_default_category_for_moves doesn't seem to work.

e7andy - as I said "code should fall back"... thanks for checking and confirming that it does not. I opened 0015226 to follow up with that

Thanks for the heads-up ( also to atrol for spotting my initial mistake ) . I'll correct the code in the soap api in a couple of hours.

Now falling back to default_category_for_moves

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch