You’re offline. This is a read only version of the page.
What's the purpose of the SalesInvoiceTMP & SalesInvoiceHeaderFooterTMP tables and can they be purged?
Is there a job already in AX that I can run to purge them routinely?
We had to add some logic to them and we're encountering a few issues. I'd like to delete them while we work out our issues.
I saw another post that said you could delete them, but they recommended doing it during a slow time so I don't delete any data that is being written to it. This makes sense and I'm planning to create a job that runs each nite.
*This post is locked for comments
I have the same question (0)As the names indicate these are to do with the sales invoice report.
Temporary tables store data in the same way as regular tables, except that they keep the data only when the object exists during code execution. In other words, when the object is finalized, then all data from the temp tables will be dropped.
There are two common situations where temp tables are applied:
So TMP tables are used to temporarily hold data e.g. in order to do validations. (Not a tempDB and the records will be deleted once the transaction completes).
The useExistingReportData method in SalesInvoiceDP class uses this statement Delete_from Table to delete records from the table e.g. see the salesInvoiceHeaderFooterTmp.delete() statement. When data is inserted under a userConnection, it is automatically deleted when the report is finished.
In a test system you can test delete the data that is stored currently in your temp table by using alt+F9 from the table browser.
This is an older related post https://community.dynamics.com/ax/f/33/t/184536
“SalesInvoiceTmp” has 200+ columns so if you add anymore for customisation then you may run into table buffer problems - last time I looked the max was 254 columns in SalesInvoiceTmp,( - that was sometime back so may have been updated. )The Default maximum buffer-size in AOS settings is 24KB try changing it to 48KB its unlikely to cause a problem.
You may also need to reset the AX user data and to refresh the AOT Elements
(This report is not the most elegant. The default Sales Invoice report approach is simple: a big table with only one column is used as a container-element. The table has some rows. In every row, one report-element is embedded, mostly tables. With this solution it is possible to print the elements one by one.
The reason why a table is used as container-element is that the table which is used as container element can be bigger than the paper size. When printing the report, the paper size which was set in the report properties is used correctly, and the report-layout is not negatively affected by unwanted page breaks.
The downside of this solution is (and thus why only one dataset is used) is that you have to assign a dataset to the table used as container element. For the elements inside this table you cannot assign other datasets than that one used in the container element table. This is the reason why Sales Invoice report is just one dataset. This a limitation, which makes report designers work a lot of harder. The move to SSRS reports form X++ was problematic at RTM - it depends on which Ax version you are now in how many of those limitations still persist.)
Share
Report
All responses (
Answers (
10,888
