Oh, I did not know about this! Sounds nice! Thank you! My problem is, that for example, one and the same product was generated twice and both of them are used either by invoices or by orders. So I changed assertion of product_id via database in account_invoice_line or purchase_order_line like described above (with reenabling constraints in the end, of course!). Seems to work... We only have some orders, invoices and account_vouchers as well as their bookings in our system - up to now, nothing else. And we do not use any special modules, only standard things. Ray, do you know, if I will get any side effects with my approach? Because I have already finished it and I believe, my database is clean now. If I risked any side effects, I would redo it using your approach (of course, I have a backup of the state before), but if the module suggested by you (I did not know the existence of) did exactly the same automatically without the necessity of database knowledge as I did manually, I would leave it like it is now...

There are other tables where you may need to change the ID - some of these are: account_move_line, mrp_bom, mrp_production, mrp_production_product_line, mrp_workcenter, procurement_order, product_packaging, product_pricelist_item, sale_order_line, stock_inventory_line, stock_move.

Okay, you have just convinced me to take the most secure way... Anyway, this is still not a big deal, because since my manual database patchings, nobody has made any changes in the system so far... So I installed ObjectMerger into my backup from before my manual patchings. It seems, that it did his job. Therefore, I will mark your solution as accepted and thank you another time for this hint. But I would still need one recommendation: ObjectMerger is a community module. The use of community modules can possibly be ... let's say ... a bit dangerous in production systems (incompatibility with system upgrades etc.). Would you therefore consider to uninstall it after having finished using it so far and reinstall it on demand? If there will be any incompatibilities in future, we won't get in trouble with our database, because in this case, it will not install, and in every case, such tests are always done in mirror databases. I think, this is the most secure way. What do you think about it? In every case, the source code of this module is really useful as it reveals which models/tables to touch when doing such database cleanings manually.