Table lock removes Doc Dim om sales line

hawkeye

Hi

My client has a problem with Sales Line beeing locked by another user (properply the NAS).

This causes a problem with the document dimensions on sales line.

I have in a clean Cronus 2009R2 Classic (Same problem in RTC) reconstructed the problem as:

- In one client I have made som code to lock the sales line rec. - I can release it on demand.
- In another client I create a sales order and new Item Line.
- After validating the Item No., I push CTRL+SHIFT+D to see the Dimensions
- The system gives me the "The sales line is locked by another user.........." message.
- I remove my lock of T37
- I change the pointer to another sales line on the sales order to insert the line (delayed insert)
- Now I go back to the sales Line and it has NO document dimensions.

My theory is, that the OnValidate "No." is not commitet because of the Locktable-error (roll Back), which mean, that i have an Item sales line with a item number in No. that has not been validated. This will be inserted because of the delayed insert, but with no document dimensions because the No. has not been validated.

My temporary solution is to make a CurrForm.SAVERECORD; on the OnValidate "No." trigger on the form, to prevent that a locktableissue will cause an Item Salesline without dimensions.

Anybody has a better soloution?

BR

Hawkeye

james_cs

What is going on is that the dimensions are not written until the line has a line no. (Autosplitkey and all that).

Your solution seems reasonable but I would be rather concerned about a NAS that locks the sales line so frequently. What does this NAS do?

An alternative solution may be to check that dimensions exist OnInsert and create them if not...

hawkeye

Yep - I have to take a look on why they keep getting the locktable error. They have a lot of jobs running all the time in the NAS. I need to think of a good soloution.

But I don´t think I can avoid locks - only minimize them, so i have to find a good soloution for the missing validation.

Your idea is good. But I think I need to validate the No. field instead as creating dimensions is not the only thing it does.

Br

Hawkeye

stryk

This sound really strange ...

Well, maybe it could help you to identify exactly this blocking issue: http://dynamicsuser.net/blogs/stryk/archive/tags/Locking/default.aspx

Then maybe you could think up a solution to fix this ...

hawkeye

VERY strange. First I used a lot of time finding a customization to cause this problem, but then I tried a clean CRONUS db and was able to recreate the error.

Its the delayed insert in combination with an error-rollback that causes the "unvalidated" "No.".

In a wonderfull wonderfull world, I wouldn´t have any blocking issues, but I´m afraid my Client will not pay me to remove them all. I/they have to learn how to live with some of them.

Br

Hawkeye

rdebath

Best guess ...

The problem is caused by the fact that the 'InsertDocDdim' and 'UpdateDocDefaultDim' functions clear the 'TempDimBuf2' table in the dimension management codeunit.

The 'InsertDocDim' function is called from the Table37 Insert trigger and it moves the records from a temp table to the database. But when NAV gets to the end of the trigger a range lock on table37 prevents the INSERT from occurring.

The changes to the database are rolled back; the changes to the temp table are not so the dimensions get lost.

Doing it in the validate works because the dimensions will be regenerated when VALIDATE("No.") is called.

Solution: Easiest is to ensure that the TempDimBuf2 won't be used outside a transaction ... ie: do a currform.saverecord.