NAV Team: Understanding Error Code 85132273 in Connection with GETLASTERRORCODE Statements

[Blog bot]

We recently received a few interesting requests about an error code appearing under particular circumstances: 85132273. This error might typically arise with the Windows Client but also with Web Services and NAS Services as well.

Digging under the hood, this error message is related to a Primary Key violation in SQL Server tables.

In most of cases, this could be due to C/AL code such as the following:

IF NOT MyTable.INSERT THEN …

This is quite an easy and diffuse syntax that looks innocent and clean (admittedly, we even have a few instances of it in the CRONUS demonstration database). However, it is a problematic use of code because it forces an INSERT into a table and if the record already exists, an implicit error is thrown. That gives us that violation of the primary key.

From a development perspective, we recommend that you refactor the code, where possible, in the following way (under a LOCKTABLE):

IF NOT MyTable.GET THEN MyTable.INSERT …

This code is preferable for at least two reasons:

1. More logically correctIt does not throw an implicit error caused by a primary key violation. Therefore developers could use GETLASTERRORCODE statement family in a more logical way. This statement family may catch, then, the violation of the primary key server side even though no visible runtime error would ever be show to the user. As short example, this code:
   
   CLEARLASTERROR;
   
   SalesPost.RUN;
   
   MESSAGE(GETLASTERRORTEXT);
   
   might display the error code 85132273 if there are nested statements like IF NOT INSERT THEN in the SalesPost codeunit.
   
   Please, be aware that this type of trapped error will not be displayed if also codeunit.RUN has a C/AL exception handling such as:
   
   CLEARLASTERROR;
   
   IF NOT SalesPost.RUN THEN
   
   MESSAGE(GETLASTERRORTEXT);
   
   In this case, any nested trapped error that might arise from IF NOT INSERT THEN will not be intercepted and no error text will be shown for this kind of violation of primary key.
2. More efficient in some cases.INSERT statements with an implicit violation of the primary key are costly and if the code is typically something like IF NOT INSERT THEN MODIFY and the number of MODIFY statements is high, the statement with IF NOT GET THEN INSERT ELSE MODIFY or, better, IF GET THEN MODIFY ELSE INSERT would be typically faster in terms of performance.

If you intend to implement error statement like GETLASTERRORMESSAGE, GETLASTERRORCODE and GETLASTERRORCALLSTACK, then you might notice that C/SIDE error code refers to a DB:RecordExists. Attached to this blog post, you will find a simple page object as proof of concept to demonstrate when and how this error might arise for a better understanding.

Please use the attached page object only for testing and understanding, and do not use it on a live environment. It is just to demonstrate the error code in a standard CRONUS demonstration database.



These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.



Duilio Tacconi Microsoft Dynamics Italy

Microsoft Customer Service and Support (CSS) EMEA

Special thanks to Peter Elmqvist from nabsolution.se

[img]//feeds.feedburner.com/~r/MicrosoftDynamicsNavTeamBlog/~4/BoW4FXv-5ns[/img]

Источник: http://feedproxy.google.com/~r/Micro...tatements.aspx