cancel
Showing results for 
Search instead for 
Did you mean: 

BOM editing

Former Member
0 Kudos

Hi

We have noticed that in our Production server BOM row deletion is super-slow (3-4 minutes per row) and that multiple row deletion is timed out. Which also causes the overall system to give timeouts (XML messaging, login etc.) So basically using multiple row deletion effectively kills the system for some time.

I've trace the error back to WIP database where is generates quite many parallel queries. And most of them are suspended until this major query finishes.

(@P0 nvarchar(4000))SELECT COUNT(BOM_COMPONENT_GBO) ROW_COUNT FROM SFC_ASSY WHERE BOM_COMPONENT_GBO=@P0

Since our SFC_ASSY tabel is huge (18,6M rows) it takes forever.

Is there anything to be done to make the BOM deletion faster?

If not - can I delete the rows manually from DB? Which tables are affected?

Br,

Jennsen

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

I think Hannes is right. This is a case of being extra cautious when deleting records. I don't think it is needed with the current BOM locking mechanism.

I would suggest you log a support ticket.

Answers (2)

Answers (2)

Former Member
0 Kudos

I created a ticket.

Former Member
0 Kudos

Hello!

From this SQl statement I suggest that there should be an index on the field BOM_COMPONENT_GBO.

Former Member
0 Kudos

Hi

I thought about that but that would be a workaround. I was wondering about the need for this query altogether.

See: the BOM editing is locked when the BOM in question has been used in production. So I do not see the need to check if the BOM has been used in production if the BOM should be locked using other methods. I think it might be some old procedure when BOM editing was allowed even when it was used.

This was the kind of answer I was looking forward 😛

Br,

Jennsen