Hi all, we have received during running the NA 3.60 client (SQL) an error: A transaction has already begun. Nested transactions are not supported. Problem is that this error message can display during running the transaction and until user click on it he blocks all users waiting for the operation. I was not able to find any description or reason of this message. Thanks, Michal
This is an internal error message really and should never happen. Is it reproducible and how? Have you repoted it officially?
Same error has come to this end also . But the scenario is that , a scheduler based activity is run to modify the data. Hence there might be a overlap in some case or the other when the two jobs in the scheduler might have got overlapped or when the job is not over and the other job might have started
I found this error in conjunction with LOCKTABLE command, but I do not remember what the problem was. It could be that I called locktable twice (or after the table had been changed already).
Not certain, but I think that 3.70 exe can fix this.
I’m having the same problem in a 3.70 B. It’s when running a scheduled procedure nighttime around 00:40, so I’m pretty sure that the disturbance is not from other users…it performs a lot of MODIFY, but I haven’t included any LOCKTABLE at all. I thought first it was a performance on the Machine running the Navision Client, cause the thing works 3 out of 5 nights…So I throw in a COMMIT every 10 Modify performed :-), …and that did not help either.
There are implicit locks in Navision as soon as you modify/insert/delete a record. Basically: This is definitely a problem in Record handling of Navision. It seems to appear when you run tasks “simultanously” (which is not really possible in Navision as it is a single threaded application). Simultanously means to call a report with RUN instead of RUNMODAL (as an example). Also calling different codeunits at different times (SI CU calling another CU which again calls a function in the SI CU) can cause this type of error. Try to call functions (codeunits) with the record as a parameter which is about to be changed, rather than running a loop (or direct get) with the same records in different codeunits. I do not know anything about your code causing this, but as I had similar problems which are now being solved, the problem is a kind of known.
We are experiencing this error on a client we recently moved to SQL 2005 (4.03 clients). They were previous 3.70 on SQL 2000. The database is still 3.70. So far ity appears to be random and have not isolated the cause.