@Dhanashri0709 Yes, as I have mentioned in my previous answer, this problem has been logged as WORDSNET-24929. Currently the issue is in the queue for analysis. We will keep you updated and let you know once it is resolved or we have more information for you.
Can you please tell me approximately how much time it will take for analysis?
@Dhanashri0709 It is difficult to tell for sure. Usually new issues are analyzed within one-two weeks.
Oh. 
It will be great if you guys able to do respond on this issue as possible as.
Thank you for response 
1 Like
Any update on this?
We have stuck with this issue so because of that we cannot release this on production with aspose.
@Dhanashri0709 Unfortunately, there are no news regarding the issue. The issue is still in the queue for analysis. We will keep you updated and let you know once it is resolved or we have more information for you.
1 Like
Any update on this?
It’s removing below element randomly after merging the attachment4.
<w:vMerge w:val=“restart” />
@Dhanashri0709 Unfortunately, there are not news yet. We will keep you updated and let you know once it is resolved or we have more information for you.
@uttamvs, we have completed the analysis of the issue. Unfortunately, we cannot provide you any reliable estimate when it will be resolved as the issue is quite complex.
@denis.shvydkiy we are using license version of aspose and this issue is impacting our business. the same is working fine with OpenXML merging.
@uttamvs, please accept our apologies for your inconvenience. We will deliver the fix according to the terms mentioned in Free Support Policies.
You can obtain Paid Support Services. In this case the issue will be treated on priority basis, along with the direct access to our Paid Support management team. Purchasing Paid Support Services will push the issue upper in the queue.
@denis.shvydkiy what is the timeline to provide fix in free support? it’s been opened from last five months.
@uttamvs, according to Free Support Policies, there is no timeline for fixes in free support. New issues get in the queue, and their resolution depends on complexity and relationship with other issues.
You mentioned that the issue is not reproducible with OpenXML SDK. If it’s not too much trouble for you, could you please post a sample code that shows how OpenSDK handles the table in Attachment4.docx? I would forward this sample code to our development team so they can check whether it can help them.
@denis.shvydkiy it’s not a new table we are creating. The table is already in template and it’s removing “<w:vMerge w:val=“restart”/>” tag from letter after merging with other documents but somehow OpenXML SDK is managing this very well.
It would be appreciated if you let us know why “<w:vMerge w:val=“restart”/>” this tag is removing? so that we can work on updating the table structure in template.
@uttamvs, Here is the analysis of the issue from our development team explaining why Aspose.Words removes the vertical merge (<w:vMerge w:val=“restart”/>).
The issue is reproducible with the attached simplified document which is based on Attachment4.docx.
simplified.docx (17.4 KB)
The table has fixed layout and a number of cells spanning multiple columns or rows. The first row of the simplified document has gridBefore. The columns spanned by the problematic vertically merged cell are not aligned between rows 1 and 2, according to MS Word cell grid span properties. If all preceding grid spans (including gridBefore) are added, the problematic cell starts at column 53 in row 1. In row 2 adding all grid spans results in the problematic cell starting at column 52. Cells starting at different columns cannot be vertically merged. AW removes the such merge.
The logic required to handle the issue is rather complex. The original table has more than 63 columns, and MS Word has a very special approach to handling such tables. The tables are treated as a series of separate “blocks” where each block has no more than 63 columns .The blocks are then combined back into a single table and cell grid spans are updated, possibly producing a more complex table with more than 63 columns.
This additional logic is not implemented in Aspose.Words yet.
@denis.shvydkiy really appreciate your explanatory reply but the question is OpenXML is managing this very well hence it is open source. Why Aspose is not managing?
@uttamvs, the logic required to handle your issue is rather complex and is not implemented yet in Aspose.Words. Please accept our apologies for your inconvenience.