0
Category:
STATUS DETAILS

Comments

It is great that you are using the profiler for investigating performance issues. We are aware of current gaps, such as more insights into actual SQL calls and outbound http call performance, but can you expand a bit on the scenarios where the profiler does not provide enough information, and the old client monitor/code coverage tools did?


For code coverage, are you aware that the snapshot debugger replay (i.e., the one used to capture a profile from VSCode) can show a quick overview of lines of code actually hit? This is somewhat similar to code coverage, although simpler. See


https://learn.microsoft.com/en-us/dynamics365-release-plan/2022wave2/smb/dynamics365-business-central/visualize-code-lines-executed-snapshot-capture


Thanks,

Peter (Microsoft)

Category:

We have this isue with some customers as well!

We need not only a link, we need attachments, pls

Category:

Agree. If we truly want to listen to our customers we need to know who they are in RTM too.

Category:

It is possible to use advanced date queries in views and entities, as described here. However, the result is a static date comparison that is determined during the database synchronisation (typically during an install of a new release). That way, it is not really suitable for proper date selection.


Instead, the date in the view can be determined dynamically, based on the current datetime (and the timezone). That way it can be used for proper date selection in entities (including virtual entities).

Category:

It is possible to use advanced date queries in views and entities as described here. However, these date queries only make sense when they are evaluated dynamically: in the current solution, the date queries are stored as a static date that is determined during the database synchronisation (typically as a part of the installation of a release).


It would be good if this behaviour was changed to use dynamic dates instead, based on the current datetime (and the timezone).


An example of a view that is defined as "all invoices with an invoice date in the future":

In the current solution, the view looks like this:


select INVOICEDATE from CUSTINVOICETABLE

   where INVOICEDATE > '2022-08-17 06:35:15'



With a dynamic date determination, it could look like this:

select INVOICEDATE from CUSTINVOICETABLE

   where INVOICEDATE > SYSDATETIME()



Thus, the change should take place in the database synchronisation, where the views/entities are created.

Category:

Very important!

Category:

I don't understand why this was developed different in Real Time Marketing compared to Outbound Marketing.

Propcess worked perfect, now it does not. Please bring it back.

Category:

Agreed, the resource having the capability of setting themselves on break without having to have permission to their work hour calendar would be really useful.

Category:

Same issue in the project table view. Please fix it!

Category:

is very frequently requested by customers

Category:

  • 1
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 500