Thanks to Jamie Weissberger from Microsoft Tech Support, this problem has a solution! He told me this:
Any field within the footer using the following expression for the visibility property causes a gap at the end of the report footer.
=iif(ReportItems!CheckStyle.Value = 0, false, true)
There are 4 fields on this report that have this hidden expression - they are the fields for the Canadian dollar amounts (the check object has 2 sets of fields - one for US dollar amounts and one for CA dollar amounts.
I had actually moved the fields above the US dollar amount fields and got the same result - a narrower bottom margin.
Solves a mystery that's been out here on MIBUSO for quite awhile since it happens in NAV2009 also!
SetSupressCommit only supresses any explicit call to Commit during the execution of the Codeunit. This allows you to include more database changes into the same transaction such as updating bookkeeping daten related to some interface to an external system. As such it is very different from Error('')
When you call to the posting codeunit to achieve this, you have then posibility of passing a "SuppressCommit" parameter to avoid commit for each recor you pass, and commited at the end.
This way if any error occurs during the hole process, the rollback do not create, modify, delete, any registers in the database
... and make sure no-one and nothing other than the BC services modifies data in the BC database, except possibly for dedicated staging tables specifically created for that very purpose.
Change log used to be triggered by the OnGlobal<Trigger> events (formerly procedures with pre-defined IDs in Codeunit 1. Those get triggered by user interactions in pages only. Modifications in code had to be logged by calling functions from within that code.
But after the OnDatabase<Trigger> events were introduced, any database operation which causes any record in the database to be changed triggers the logging.
Gotchas I am aware of:
inserts for records with autoincrement fields do not record the correct value for that field, because the event is called with data from before the database insert operation (Edit: actually, I believe, before the database insert actually occurred. I could not find any way to find the missing value from within OnGlobalInsert (Auto increment fields are typically used as primary key)). I assume the same will be true for Timestamp fields, but I have not checked this out.
the first updating database operation on a table triggers the event GetDatabaseTableTriggerSetup. Changes to the Change Log setup after this point will get active only after you start a new session. Changing the fields to be logged is not affected by this restriction.
I do have no experience with change log for fields defined in table extensions.
What is the page they getting this issue with? Is it random or one specific page? Change log only logs change in fields where data is entered and saved. If data is not saved in the fields then it wont record anything.
To remove password protection from PDF File, try SysTools PDF Password Remover Tool, one of the trusted and reliable software. This tool comes with advanced features to unlock password-protected PDFs. Using this software, you can remove protection like editing, printing, copying, and more. Additionally, it lets you clear open document passwords and owner restrictions. So, download this robust tool on your Windows or Mac OS to access the unlocked PDF.