Вернуться   AXForum > Блоги > Logger
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

  1. Старый комментарий
    Запись от Logger размещена 03.09.2019 в 14:53 Logger is offline
  2. Старый комментарий
    Запись от Logger размещена 09.06.2019 в 23:32 Logger is offline
  3. Старый комментарий

    X++, the catch Michael Fruergaard Pontoppidan November 24, 2016

    Velislav M
    November 29, 2016 at 9:03 am
    Not a fan of compiler magic, but this is an example of how syntax sugar makes us fat and lazy. Can we have some more, please!
    We already know what the correct “catch-all” block should look like…
    So, why can’t we have a keyword that automatically emits all the boilerplate code for handling correctly the update-conflict and duplicate-key exceptions?

    I mean, going forwrad, it would be nice if we could write code that can be fully covered by unit tests without too much hassle.
    And creating a macro, or a separate class, for just handling transaction exceptions is simply not as good.
    Sometimes, more control will be needed, but most of the time people will be just fine with a “smart default”

    Log in to Reply
    November 25, 2016 at 3:33 pm
    Michael, I believe that it is necessary to fix the core.

    Correction in X ++ code has a number of problems:
    1. Not all developers know about the bug discussed and probably will never know. (Moreover, few people know ). It is therefore not correct to be a bug. The bug will remain forever. For example, I posted information about it on axforum in 2011, but so far very few people know about it in Russia. (axforum – the only Russian-language resource on DAX)
    2. Most of the developers since Ax3, accustomed that the transaction is atomic and X ++ supports it (Acid). But this is not the case.
    3. Documentation X ++ explicitly recommends that you can use Exception- All. It is not enough to recommend the developers to correct the X ++ code. At the same time it is necessary to fix the system documentation.
    4. In reality, now the developer is forced to constantly think about the danger and cumbersome to write exception handling. This is extremely inconvenient and prevents focus on the essentials. X ++ in this case, – makes life difficult, not easier.
    5. Find all the places in the code that must be very difficult to correct. (They are still many standard code)

    In the case of kernel patches:
    1. Developers do not need to be aware of this bug and a lot of problems with uninformed programmers disappears.
    2. Acid still been supporting X ++. Software really gets what he expects and what it was used since ax3
    3. It is not necessary to correct the documentation – the system will start to work as well as recommended in the documentation.
    4. Exception handling code is again very simple. There is no need to think about the complex. (This is the main reason. Most developers will simply be happy by this simplification.)
    5. Do not look for a lot of places in the code X ++ to fix. It is enough to put a fix for the kernel! I think you will agree that it is much easier than to review and analyze all of the source X ++ code. In addition, a bug often works, But users and programmers do not notice it. For them, the situation looks like in the middle of a transaction to commit. Now all is corrected itself.

    And further:
    I do not know the kernel source code, but I think that to correct the mistake would not be very difficult as the kernel, when exiting ttsBegin/ttsCommit scope – changes ttslevel, ie kernel monitors the level of the transaction. I think that we should not reduce the tts-counter by 1, but the transaction counter is to be reseted to 0. It will be safer. (In this case, we do not renounce the TTSunrollbackable exceptions. Only fix their behavior)

    Log in to Reply
    Metin Emre
    November 28, 2016 at 4:57 pm

    I think this’s not a bug. first record saved, while second is saving there’s an error occurs and you decided what’ll do in catch. You can ignore the bug, or you can throw an error and break the transcaction. That’s logical. However I never noticed this behaviour until today and in first a bit shocked.

    Thanks for article…

    Log in to Reply
    November 25, 2016 at 8:41 am
    thanks for post.
    It’s stupid core bug, as i see.
    That ‘trick’ don’t happens in old version of AX. I check it on AX4, and when raise UpdateConflict on the line of credit update, code goes to catch in postList method. And therefore, without any violation of transactional integrity.

    Log in to Reply
    Michael Fruergaard Pontoppidan
    November 25, 2016 at 9:09 am
    Thanks! That is very useful information. I’ve tried this in AX2012 R3 and AX7. Both have this problem. Does anyone have an AX2009 they can try on?

    Log in to Reply
    November 25, 2016 at 12:49 pm
    I’ve tried in ax2009.
    Bug exists and caused some problem in production.

    I described this here
    Развалились InventSum - InventTrans

    Here is brief translation
    The job :
    static void Job791_15(Args _args)
    #define.recIdTrans(5637151827) // here must be existsing recid from InventTrans.
    InventTrans InventTrans;
    InventSum InventSum;
    InventTrans = InventTrans::findRecId(#recIdTrans, true);
    InventTrans.Qty += 1.0;
    info(“Catched inner catch”);
    info(“Catched outer catch”);

    info(strFMT(“InventTrans.RowCount() = %1, InventTrans.Qty = %2, InventSum : %3 “,
    con2str(Global::buf2Con(InventSum::find(InventTrans.ItemId, InventTrans.inventDimId)), “; “)


    How to use:
    1. Edit job, setting in line 3 the recid of existing InventTrans.
    2. Open 2 ax client.
    3. Run the job on the first client and wait when it stops in debugger.
    4. Run the job on the second client and wait. Client must hang. It wil be blocked by first client.
    5. Press F5 in debugger for first client.
    6. Press F5 in debugger for second client.
    So, both jobs are to be performed.
    As result, InventTrans.Qty increases by 1.0 and the apropriate column in InventSum increases by 2.0

    November 25, 2016 at 1:10 pm
    It can not be reproduced in ax3 because it does not support Exception::UpdateConflict and Exception:uplicateKeyException

    Michael Fruergaard Pontoppidan
    November 26, 2016 at 7:41 am
    Hi AGolubkov,
    What is the build number of AX4 you tried on? I looked at the compiler/interpreter code in AX4 vs AX2009 and found nothing indicating the behavior should be different.

    UPDATE: I tried on AX4SP1, it also has this problem. I’m going to assume this has been an issue since the new exception types got introduced.
    There is an image showing it here:


    Log in to Reply
    February 2, 2017 at 8:33 am
    Hi Michael,
    sorry for late reply, I didn’t see your question.

    I’ve tried it on application Dynamics AX 4.0 SP2 4.0.2501.116, and hadn’t any problems with trasactional integrity in this example.

    February 2, 2017 at 8:38 am
    Hi Michael,
    soryy for late reply, I didn’t see your question…

    I’ve tried this example in DAX application Dynamics AX 4.0 SP2 4.0.2501.116.
    And I didn’t see any problem with transactional integrity.

    November 24, 2016 at 5:47 pm
    Nice post. Do you have any ideas how to find such ‘unsafe’ code in the existing application

    Log in to Reply
    Michael Fruergaard Pontoppidan
    November 24, 2016 at 7:12 pm
    Hi Denis, there are many ways to find them. As I had all source files on disk (I’m on the AX7 stack), I did a “findstr /i /s /C:”catch” *.* >catches.txt”. Then I used Notepad++ to filter out the noise. Within a few minutes I had the list of potential problems, and I then started the investigation in Visual Studio. There are other (and likely more efficient) ways – but this did the job for me.


    Log in to Reply
    November 25, 2016 at 4:19 am
    By the way – can you register this issue as a bug?
    It seems more logical that the language should guarantee that what is written between ttsbegin.. ttscommit should be considered as one transaction, not just the way that developer write code

    Michael Fruergaard Pontoppidan
    November 25, 2016 at 9:13 am
    Let us assume this is a compiler bug, and it get resolved as a KB. How long will it take before all systems in the world are patched? Wouldn’t it be better to write code that is reliable with and without the fix. Another complicating factor is that all X++ must be recompiled for an eventual fix to have any effect. Rest assured the X++ compiler team is informed; and this thread will be updated with news.

    November 29, 2016 at 1:36 pm
    Hi Michael.

    >> Never use catch “all” without explicitly catching updateConflict and duplicateKey exceptions.

    I suggest to create a BestPractice check, verifying before the code “Catch-ALL” is always exists “catch (Exception::UpdateConflict)” and “catch (Exception:uplicateKeyException)”

    What we get:
    1. There will be found all the places that need to be fixed, with the global compilation.
    2. If one uses Exception incorrectly, BP check warns programmer. So, code will be fixed immediatly.
    3. In the future, it will be easier to maintain the correct code.

    Martin Dráb
    November 24, 2016 at 3:55 pm
    A nice demonstration of an ugly problem.

    It also shows that X++ / AX lacks tools for developers to handle exceptions correctly – catch clauses in “What does reliable code look like?” take more than 30 lines. Also, X++ doesn’t have a statement for re-throwing the same exception (as throw; does in C#).

    There are also other issues with exception handling. If anybody can break my exception handling logic just by calling my method from inside a transaction, it means that I can’t really rely on it. Together with the fact that exceptions don’t carry additional details such as a type (something like FileNotFoundException) it leads to a complete absence of code for recovering from errors (people either let the process stop, or handle all exceptions, as in this post).

    Generics and better exceptions are my top two things I would like to see in X++.

    Log in to Reply
    Michael Fruergaard Pontoppidan
    November 24, 2016 at 7:23 pm
    Hi Martin, As this post points out, it is actually possible to handle exceptions in X++ correctly, and it is possible to write a method that cannot be broken by a consumer. My hope is that this post will enable X++ developers to do so.

    I do agree that handling of exceptions is much too hard and much too verbose in X++; and there is plenty of room for improvements.


    Log in to Reply
    November 25, 2016 at 11:19 pm
    So it is a bug in the core which is at least 5 years old and we have a solution now: “Just avoid holding it in that way”. Cheers

    Martin Dráb
    November 27, 2016 at 2:57 am
    Micheal, I mean that if I want, for example, all errors to be logged and then continue processing (or use any other arbitrary error handling logic), all my logic is ignored when somebody calls my logic from inside of another transaction.
    Your post doesn’t show how to address it and it can’t, because it’s not possible. Your post is clearly about exceptions that don’t have this problem, because they actually *can* be handled inside transactions.

    Michael Fruergaard Pontoppidan
    November 28, 2016 at 7:57 am
    Thanks for the elaboration, Martin. The original design of transaction and exception handling in AX was to ensure data integrity – at the cost of flexibility. Giving back the full flexibility as you are requesting without risking data integrity is an interesting challenge. (As this post shows).
    Запись от Logger размещена 03.06.2019 в 09:43 Logger is offline
  4. Старый комментарий

    Разное интересное чтобы не забыть

    Как пишут расширения для редактора.
    Пошаговая инструкция
    Запись от Logger размещена 14.05.2019 в 14:39 Logger is offline
  5. Старый комментарий
    Запись от Logger размещена 08.11.2018 в 10:30 Logger is offline
    Обновил(-а) Logger 08.11.2018 в 10:39
  6. Старый комментарий

    Разное интересное чтобы не забыть

    AX2012 Upgrades – Setting a clean AX2012 database to start with the upgrade check-list and not the Initialization check-list.

    As some of you who work on AX 2012 Upgrades may already know, you need to select the AOS along with the Database option in the AX setup to get the “Register this database for Upgrade” option.

    However, if you already have an AOS service installed and want to setup a new database for an upgrade, sometimes you don’t want to install another AOS just to do get this option. If this is the case, you can run the following script as a workaround to modify the database after the install, so that the upgrade checklist is shown when you start the client:







    DELETE FROM SysSetupLog

    WHERE NAME = ‘SysCheckList_Setup’

    OR NAME LIKE ‘SysCheckList_Up%’

    The statement creates the required stored procedure for the SysCheckList classes to identify this is an upgrade database, and in case you have already started the initialization check-list, it also removes any previous records from SysSetupLog.

    As with any direct updates to the database, it is recommended that you make a backup so you can restore the database if required. Also, only use this on a newly installed database!

    Maxim Gorbunov
    If upgrading from 4.0 or 2009 to AX 2012 R2, you also have to switch to table-per-type table inheritance mode (see Data Upgrade Best Practices (White Paper) for details, To do so, you have to create one more stored procedure in addition to that mentioned above:



    Is there any way to do it the other way around? I have checked the option "register the database for upgrade" during setup but I do not want to run any of the upgrade checklists so I want to remove the "register the database for upgrade" option. Is that possible or do I have to reinstall the database and AOS?

    5 years ago
    Hi Johan,

    You could try dropping the Stored Procedure "[dbo].[SETUPVERSIONPROC]". This is only created when you select the option "register the database for upgrade". If this is not present it will assume that this is a fresh install and not for an upgrade. You may also need to run the DELETE statement above on the SysSetupLog table. I've not tested this, but from what I found when looking at this in the past, I believe it should work.

    Thanks, Thomas
    Запись от Logger размещена 21.09.2018 в 17:57 Logger is offline
  7. Старый комментарий
    Запись от Logger размещена 25.04.2018 в 10:14 Logger is offline
  8. Старый комментарий

    Разное интересное чтобы не забыть

    Средство тестирования производительности в Dynamics 365 for Finance and Operations
    Запись от Logger размещена 07.02.2018 в 13:42 Logger is offline
  9. Старый комментарий
    Запись от Logger размещена 23.01.2018 в 17:29 Logger is offline
  10. Старый комментарий
    Запись от Logger размещена 11.01.2018 в 09:59 Logger is offline
  11. Старый комментарий
    Запись от Logger размещена 11.01.2018 в 02:02 Logger is offline
  12. Старый комментарий
    Запись от Logger размещена 11.01.2018 в 01:52 Logger is offline
  13. Старый комментарий
    Запись от Logger размещена 11.01.2018 в 01:38 Logger is offline
  14. Старый комментарий

    Разное интересное чтобы не забыть

    Автоматизированная диагностика проблем с Аксаптой (Support Diagnostic Packages, SDP; контрольные списки для выявления известных проблем)
    Автоматизированная диагностика проблем с Аксаптой (Support Diagnostic Packages, SDP; контрольные списки для выявления известных проблем)
    Запись от Logger размещена 11.01.2018 в 01:28 Logger is offline
  15. Старый комментарий

    Разное интересное чтобы не забыть

    Очень подробное исследование, касающееся отличия скорости выполнения запросов в приложениях и Management Studio
    А при чем тут курсоры, не курсоры? кардинальное отличие во времени могут дать только разные планы
    Запись от Logger размещена 11.01.2018 в 01:17 Logger is offline
  16. Старый комментарий
    Запись от Logger размещена 11.01.2018 в 01:11 Logger is offline
  17. Старый комментарий
    Запись от Logger размещена 10.11.2017 в 13:21 Logger is offline
  18. Старый комментарий
    Запись от Logger размещена 07.03.2017 в 12:57 Logger is offline
  19. Старый комментарий
    Запись от Logger размещена 07.03.2017 в 11:44 Logger is offline
  20. Старый комментарий
    Запись от Logger размещена 22.02.2017 в 22:53 Logger is offline

Часовой пояс GMT +3, время: 06:37.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.