web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Query Displaying different number of rows in different situations

(0) ShareShare
ReportReport
Posted on by

I have built a query that is acting very oddly. When I bind it directly to a view, it populates 36 rows, yet when I pass the same query as a dataset to an SSRS report, it only populates 12 rows. Is there anything that might be able to account for this? All parameters are identical.

Additionally, in the SSRS report, fields are returning blank. Some of these fields are selected in inner joins, and they do not match the values of the fields they are joined to (which are obviously not blank). When running the view inside of AX, I do not see this. When I recreate a SQL statement that mimics the query I built in AX, I see the same 36 rows I would expect with all of their fields properly populated.

I have tried clearing all of the caches, have cycled both the AOS and the RS services, and even booted the box that they are on, so I'm more or less positive that this is not the result of a cached problem.

Has anyone seen anything like this?

*This post is locked for comments

I have the same question (0)
  • Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    Hello

    For the first part of your question you should be aware of the date effective framework and the crosscompany settings in the different AOT objects.

    For the second part of your question, it's not possible to find an answer without posting your original query.

    Regards

    Hans-Peter

  • Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    The crosscompany system I'm aware of and taking account for, but how would I deal with the date effective framework as data is being passed to the SSRS report? The main reason this confuses me so badly is that inside of AX, when I look at the view which populates from my query, I see all 36 rows that I'm expecting in the report.

    The query that I'm using is one that I've built in the AOT. What is the best way for me to share it with you? I can export it to an XPO, but it includes fields that are custom to this implementation, so that might be of limited use to you.

    Also, thank you for the help here, it is very appreciated!

  • Verified answer
    Vilmos Kintera Profile Picture
    46,149 on at
    RE: Query Displaying different number of rows in different situations

    With a system administrator account you could go to File > Tools > Options, and enable SQL Trace for long executing queries with setting 0 ms as the time, and set target to infolog.

    After that if you run your code or table browse, it would capture what does AX send to the SQL Server (without the parameter bindings).

    That could give you an idea on what are you missing when building the custom query. It could be a whole range of issues, like the above mentioned legal entity handling, validtimestate key tables, doing exists/inner/outer joins or having fetch mode set incorrectly or in the wrong order and so on.

  • Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    Here is the SQL that the view I built (by populating the view based by dragging all the fields from my query into it) is using. This view returns all 36 rows correctly when I open it. The SSRS report uses the exact same query, but only has 12 rows, some of which are unpopulated. It is the difference between these two that is most confusing.

    SELECT T1.BACKORDERSTATUS,
          T1.DLVDATE,
          T1.INVENTDIMID,
          T1.INVENTREFID,
          T1.INVENTREFTYPE,
          T1.ITEMID,
          T1.NAME,
          T1.PRODID,
          T1.QTYSTUP,
          T1.RECID AS RECID1,
          T1.STUPDATE,
          T1.ROUTEID,
          T1.DATAAREAID,
          T1.PARTITION,
          T1.RECID,
          T2.DATAAREAID AS DATAAREAID#2,
          T2.PARTITION AS PARTITION#2,
          T2.INVENTDIMID AS INVENTDIMID1,
          T2.ITEMID AS ITEMID1,
          T2.OPRNUM,
          T2.POSITION,
          T2.QTYINVENTCALC,
          T2.QTYINVENTSTUP,
          T2.REMAININVENTPHYSICAL,
          T2.UNITID,
          T2.BOMID,
          T2.INVENTTRANSID,
          T2.BACKORDERSTATUS AS BACKORDERSTATUS1,
          T3.DATAAREAID AS DATAAREAID#7,
          T3.PARTITION AS PARTITION#7,
          T3.BACKORDERSTATUS AS BACKORDERSTATUS2,
          T3.CALCPROC,
          T3.CALCSETUP,
          T3.FROMDATE,
          T3.FROMTIME,
          T3.OPRID,
          T3.OPRNUM AS OPRNUM1,
          T3.OPRNUMNEXT,
          T3.PROCESSCATEGORYID,
          T3.PRODID AS PRODID1,
          T3.SETUPCATEGORYID,
          T3.TODATE,
          T3.TOTIME,
          T3.PROCESSPERQTY,
          T3.PROCESSTIME,
          T3.OPRFINISHED,
          T4.DATAAREAID AS DATAAREAID#9,
          T4.PARTITION AS PARTITION#9,
          T4.ITEMID AS ITEMID2,
          T4.PRODUCT,
          T5.DATAAREAID AS DATAAREAID#10,
          T5.PARTITION AS PARTITION#10,
          T5.CONFIGID AS CONFIGID1,
          T5.INVENTBATCHID,
          T6.DATAAREAID AS DATAAREAID#11,
          T6.PARTITION AS PARTITION#11,
          T6.NAME AS NAME2,
          T7.DATAAREAID AS DATAAREAID#12,
          T7.PARTITION AS PARTITION#12,
          T7.NAME AS NAME3,
          T7.BOMID AS BOMID1,
          T8.DATAAREAID AS DATAAREAID#3,
          T8.PARTITION AS PARTITION#3,
          T8.NAME AS NAME1,
          T9.DATAAREAID AS DATAAREAID#4,
          T9.PARTITION AS PARTITION#4,
          T9.CONFIGID,
          T10.DATAAREAID AS DATAAREAID#5,
          T10.PARTITION AS PARTITION#5,
          T10.ABCCONTRIBUTIONMARGIN,
          T11.DATAAREAID AS DATAAREAID#6,
          T11.PARTITION AS PARTITION#6,
          T11.LINENUM,
          T11.INVENTCONSUMP,
          T11.INVENTTRANSID AS INVENTTRANSID1,
          T12.DATAAREAID AS DATAAREAID#8,
          T12.PARTITION AS PARTITION#8,
          T12.HOURS,
          T12.QTYGOOD,
          T12.QTYERROR,
          T12.OPRFINISHED AS OPRFINISHED1,
          CAST(NULL AS NUMERIC(32, 16)) AS PDSCWBATCHSTUP,
          CAST(NULL AS NUMERIC(32, 16)) AS PDSCWINVENTCALC,
          CAST(NULL AS NUMERIC(32, 16)) AS PDSCWINVENTSTUP,
          CAST(NULL AS NUMERIC(32, 16)) AS PDSCWREMAINPHYSICAL
    FROM dbo.PRODTABLE AS T1
    LEFT OUTER JOIN dbo.PRODBOM AS T2
       ON T1.PRODID = T2.PRODID
       AND T1.DATAAREAID = T2.DATAAREAID
       AND T1.PARTITION = T2.PARTITION
    LEFT OUTER JOIN dbo.PRODROUTE AS T3
       ON T1.PRODID = T3.PRODID
       AND T1.DATAAREAID = T3.DATAAREAID
       AND T1.PARTITION = T3.PARTITION
    INNER JOIN dbo.INVENTTABLE AS T4
       ON T1.ITEMID = T4.ITEMID
       AND T1.DATAAREAID = T4.DATAAREAID
       AND T1.PARTITION = T4.PARTITION
    INNER JOIN dbo.INVENTDIM AS T5
       ON T1.INVENTDIMID = T5.INVENTDIMID
       AND T1.DATAAREAID = T5.DATAAREAID
       AND T1.PARTITION = T5.PARTITION
    INNER JOIN dbo.ROUTETABLE AS T6
       ON T1.ROUTEID = T6.ROUTEID
       AND T1.DATAAREAID = T6.DATAAREAID
       AND T1.PARTITION = T6.PARTITION
    INNER JOIN dbo.BOMTABLE AS T7
       ON T1.BOMID = T7.BOMID
       AND T1.DATAAREAID = T7.DATAAREAID
       AND T1.PARTITION = T7.PARTITION
    INNER JOIN dbo.BOMTABLE AS T8
       ON T2.BOMID = T8.BOMID
       AND T2.DATAAREAID = T8.DATAAREAID
       AND T2.PARTITION = T8.PARTITION
    INNER JOIN dbo.INVENTDIM AS T9
       ON T2.INVENTDIMID = T9.INVENTDIMID
       AND T2.DATAAREAID = T9.DATAAREAID
       AND T2.PARTITION = T9.PARTITION
    INNER JOIN dbo.INVENTTABLE AS T10
       ON T2.ITEMID = T10.ITEMID
       AND T2.DATAAREAID = T10.DATAAREAID
       AND T2.PARTITION = T10.PARTITION
    INNER JOIN dbo.PRODJOURNALBOM AS T11
    LEFT OUTER JOIN dbo.PRODJOURNALROUTE AS T12
       ON T3.OPRPRIORITY = T12.OPRPRIORITY
       AND T3.DATAAREAID = T12.DATAAREAID
       AND T3.PARTITION = T12.PARTITION
       AND T3.OPRNUM = T12.OPRNUM
       AND T3.DATAAREAID = T12.DATAAREAID
       AND T3.PARTITION = T12.PARTITION
       AND T3.PRODID = T12.PRODID
       AND T3.DATAAREAID = T12.DATAAREAID
       AND T3.PARTITION = T12.PARTITION 
    ON T2.INVENTTRANSID = T11.INVENTTRANSID AND T2.DATAAREAID = T11.DATAAREAID AND T2.PARTITION = T11.PARTITION
  • Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    Also, I should note here that I am filtering the ProdId value on the prodtable when the report actually runs.

  • Suggested answer
    Vilmos Kintera Profile Picture
    46,149 on at
    RE: Query Displaying different number of rows in different situations

    Are you sure the reporting instance which is configured in your environment pointing at SSRS (check the SRSServers table for the specific AX AOS you are connected on in that table), and the SSRS instance is pointing back to the same AOS?

    Open the AX client configuration tool with the executin account set in the Report server configuration on the SSRS server and see if it is pointing at the right AX AOS. Maybe you are mix-and-matching various dev/test environments and the data is coming from a different system that you are expecting.

    You could try to capture the incoming SQL statement requests on the SQL Server instance where you think your environment is connecting. Open your view in the AOT, then also run the report. See if they get captured in the log. If not, then your datasource is not the same and that is why you are seeing wrong values.

    Also it could be that the records are physically deleted in SQL, but AX is retrieving cached values - to be sure yous hould restart your AX AOSes to drop the cache.

  • Ali Zaidi Profile Picture
    4,655 on at
    RE: Query Displaying different number of rows in different situations

    Hi I think you are execute Query in SQL Server. In SQL query run against all legal entities where this filter by default set in SSRS or AOT. If you run the query in SQL server then add filter against dataarea or DataAreaId in Query tables.

  • Verified answer
    Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    First, thank you to everyone who offered advice on this one, it really took me some time to track it down.

    The short answer is this: 1:n was set as the fetchmode for the Query, which fetches the data for joined tables separately.

    The View that is constructed from a Query in AX does not respect fetchmode, which is why the view was returning correct data. Because the Query was being consumed outside AOS, the delayed fetch became a *never* fetch. This is what was accounting for missing data and seemingly nonsensical number of returned rows.

  • Vilmos Kintera Profile Picture
    46,149 on at
    RE: Query Displaying different number of rows in different situations

    Thought so, mentioned fetch in my first post for the exact same reasons. Make sure you mark that as an answer for the topic as well.

  • Community Member Profile Picture
    on at
    RE: Query Displaying different number of rows in different situations

    Done and done. Yeah, my mistake was based on a misunderstanding of how the setting worked.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Abhilash Warrier – Community Spotlight

We are honored to recognize Abhilash Warrier as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Tocauer Profile Picture

Martin Tocauer 4

#1
Community Member Profile Picture

Community Member 4

#3
Nayyar Siddiqi Profile Picture

Nayyar Siddiqi 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans