a commit fired up an Transaction end to the SQL Server. so, the locks into the transaction are released. But like kine sayed. You must know when you set the commit.
Better, for the lock problem, check why there are locks. Is there are "stupid" keys like under "dimensions", there are many SIFTs to create / delete / update, there are many recs to update / delete / create, is the C/AL Code not good enought for a better perfomance, etc :?:
so, you see, many question, for one little post ;-)
Well the code is not mine and I'm trying to solve locktable issue.
The code is like this. The table has "entry no." as PK
Table.Locktable.
if table.findlast then;
LastEntryNo := table."Entry No." + 1;
table.reset;
table."Entry No." := LastEntryNo;
table."Populate other fields"
table.insert;
commit;
form.runmodal(0,table);
What is a good way to solve the locktable issue.
back to the start... What are you trying to archive. It looks like you are trying to get user interaction during a transaction. Much like that absolutely awful bit of code that checks the credit status of a client when entering a sales order.
You need to rethink the business logic and redesign it.
Not all business requirement can be solved by code unfortunately. And its even worse when you have existing code you need to work with.
This is not during any transaction (posting). The data gets prepopulated before the form is opened. Thats all it is.
The user then populates additional data and closes the form.
Anyway, it is a transaction (Data Create) ;-) And you can't run a form / report in Runmodal mode during a transaction, so u use the commit to end the transaction.
So, but where is there the problem with the commit? OK, its not very nice, but the first transaction is to insert the recs. Is this finish, end the Transaction (commit). After the commit is a form runmodal. These runmodal doesn't block other users (if there is no locking code in the form), it's the same thing when he fill the table behind Button1 and call the form from Button 2. Both are sep. transactions. It's the same thing when he run first the form and insert from there the Recs with using a function on Form, like, Function -> "Insert Recs from Anywhere"
Do you have seen where the blocks occur :?: And which table is locked? the table where u insert or a other table?
This is not during any transaction (posting). The data gets prepopulated before the form is opened. Thats all it is.
The user then populates additional data and closes the form.
Then I think you need to be a bit clearer in what you are doing. As Garak has said, if this is not in the middle of a transaction, then no locking should be occuring. It could be that you are on a "bad" version, so let us know which NAV version you are on , service paks updates and hot fixes.
ALso take a look at Waldo's Blog, to see where you need to be:
Comments
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Better, for the lock problem, check why there are locks. Is there are "stupid" keys like under "dimensions", there are many SIFTs to create / delete / update, there are many recs to update / delete / create, is the C/AL Code not good enought for a better perfomance, etc :?:
so, you see, many question, for one little post ;-)
Regards
The code is like this. The table has "entry no." as PK
Table.Locktable.
if table.findlast then;
LastEntryNo := table."Entry No." + 1;
table.reset;
table."Entry No." := LastEntryNo;
table."Populate other fields"
table.insert;
commit;
form.runmodal(0,table);
What is a good way to solve the locktable issue.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
back to the start... What are you trying to archive. It looks like you are trying to get user interaction during a transaction. Much like that absolutely awful bit of code that checks the credit status of a client when entering a sales order.
You need to rethink the business logic and redesign it.
Not all business requirement can be solved by code unfortunately. And its even worse when you have existing code you need to work with.
The user then populates additional data and closes the form.
So, but where is there the problem with the commit? OK, its not very nice, but the first transaction is to insert the recs. Is this finish, end the Transaction (commit). After the commit is a form runmodal. These runmodal doesn't block other users (if there is no locking code in the form), it's the same thing when he fill the table behind Button1 and call the form from Button 2. Both are sep. transactions. It's the same thing when he run first the form and insert from there the Recs with using a function on Form, like, Function -> "Insert Recs from Anywhere"
Do you have seen where the blocks occur :?: And which table is locked? the table where u insert or a other table?
Regards
Then I think you need to be a bit clearer in what you are doing. As Garak has said, if this is not in the middle of a transaction, then no locking should be occuring. It could be that you are on a "bad" version, so let us know which NAV version you are on , service paks updates and hot fixes.
ALso take a look at Waldo's Blog, to see where you need to be:
Platform updates overview