Currently we use the editDeletePageCheck stored procedure to identify blocks that are no longer being used, allowing us to then deprecate these blocks. It appears the stored procedure works for blocks in the CMS; however, for commerce 0 is returned even when the blocks are currently active in commerce. This is causing issues and we are deprecating blocks that are currently being used in commerce.
Per Episerver...
This is because the softlink API (in CMS) has a foreign key restraint that requires that the owning content (i.e. the content linking to the block in your scenario) exists in tblContent. Catalog content is stored in the Commerce DB. The long term solution would be to open up the softlink API to allow storing links regardless of where the content is stored. The CMS team would have to build the "extendable softlinks"-feature and then the commerce team would have to build on top of that.
Currently we use the editDeletePageCheck stored procedure to identify blocks that are no longer being used, allowing us to then deprecate these blocks. It appears the stored procedure works for blocks in the CMS; however, for commerce 0 is returned even when the blocks are currently active in commerce. This is causing issues and we are deprecating blocks that are currently being used in commerce.
Per Episerver...
This is because the softlink API (in CMS) has a foreign key restraint that requires that the owning content (i.e. the content linking to the block in your scenario) exists in tblContent. Catalog content is stored in the Commerce DB. The long term solution would be to open up the softlink API to allow storing links regardless of where the content is stored. The CMS team would have to build the "extendable softlinks"-feature and then the commerce team would have to build on top of that.