Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: New page number on change of group no longer working. (DR 6.1.5.9607)

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Default New page number on change of group no longer working. (DR 6.1.5.9607)

    Dataflex Reports.
    New page number on change of group is no longer working.

    This is causing issues as we are now having to manually calculate the page number (with formulas and global variables) for our invoice runs, and we know no way of working out how to do a {Page N of M}. This is something customers are asking for, and it's something which is continuing to cause us great embarrassment.

  2. #2
    Join Date
    Feb 2009
    Location
    Hengelo, Netherlands
    Posts
    10,869

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Sean,

    Please create a ticket in HDE (https://hde.dataaccess.eu) with this problem and attach a report that can be executed to see where the problem is.
    Regards,
    Data Access Worldwide
    Vincent Oorsprong

  3. #3

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Page numbering is not working when the page number field is placed at the top of the report (In the group header).

    Even when the Page number field is placed at the bottom of the report, the issue occurs if the group footer falls off the bottom of report without an associated detail line. (i.e. the group footer appears on its own on the second page)

    Please file the bug yourselves, and see if you can replicate the issue before making me spend even more time on this.
    I have wasted hours of unbillable time on this, and I don't see why I should continue to do so.

  4. #4
    Join Date
    Feb 2009
    Location
    Houston, Tx
    Posts
    49

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    > I have wasted hours of unbillable time on this, and I don't see why I should continue to do so.

    Actually there IS a reason: If you don't manually enter all your relational data into the report via the studio (AT YOUR EXPENSE), no action will be taken by DAC.EU toward resolving your problem. Yes, it's a tedious process.

    I have already reported this same bug on October 9th of last year (DR 6.1.4). It is HDE Ticket #5030, and I provided a lot more information about what's going on. I always try to provide enough concise documentation so that a programmer can dive in with an editor and probably fix the problem straight away.

    With this bug I went through the same process as you. In order to start page numbering in a group header, you must reset the page number in the group footer (which doesn't work). So you define global variables and functions to replicate the page number and reset it. That works, but when you use "Page N of M", there is no way to replicate the M variable which should be the total pages in the GROUP, not the whole report. So we must wait, and continue paying the annual subscription fee in order to obtain the eventual fix. Since I have several HDE tickets outstanding, I've gained a certain amount of insight as to how things work at DAC.EU. They can't replicate any problem unless you send them manually entered relational data created within the studio. Their debugging environment is the DR studio.

    I think DR is a great product, except for one small area: Several of the checkbox options in the section expert (and certain other of the experts) will not result in reports that paginate correctly - especially when the options are used in combination, or with variable length sections or subreports. Pages break at the wrong place, pages don't number correctly, printing that belongs on the bottom of the page is printed at the top, etc, etc. I have long had the impression that these problems are the work of a single coder - and it makes the whole team look bad because any but the simplest of reports have obvious bugs which end users will certainly notice. We developers are caught in the middle.

    Like you, I have refused to manually enter the data. My expense in reporting bugs to DR support exceeds the license registration fee many times over, and I have little to show for my efforts because my bug documentation never reaches that coder's inbox. The problem is that a tool is needed for developers to easily upload their production data into the studio before posting .DR files to support. This would eliminate the expensive task of manual entry, which has become a serious obstacle in the resolution of bugs in Dataflex Reports. I've been told (you can guess by whom) that this tool will be written in JSON, and it's exactly what we are all waiting for.

  5. #5
    Join Date
    Feb 2009
    Location
    Hengelo, Netherlands
    Posts
    10,869

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Sean,

    I cannot log this in HDE as I don't have your company name and contact information to file it under.

    Please notice that the forums are for peer-to-peer support and HDE is our published location for filing a bug or wish.
    Regards,
    Data Access Worldwide
    Vincent Oorsprong

  6. #6
    Join Date
    Feb 2009
    Posts
    130

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Fixed in next rev.

  7. #7
    Join Date
    Feb 2009
    Location
    Queens, NY, NY
    Posts
    7,429

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    And the release date for this new rev is?
    Michael Mullan.
    Danes Bridge Enterprises.

    ++++++++++++++++++++++++++++
    There is just today. Tomorrow is a concept
    that is mostly theoretical. -- GM Wylie
    ++++++++++++++++++++++++++++

  8. #8
    Join Date
    Apr 2016
    Location
    New Zealand
    Posts
    302

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Using DR6.1.5
    Tested in DR6.2 but still has the same problem

    We have a report that has 2 groupings. One for customer and then second for order#

    Group#1 Customer
    |
    ----Group#2 Order#
    |
    ----Detail Section
    |
    Group#2 Order# Footer
    |
    Group#1 Customer Footer

    In the Group#1 Customer footer - I set the reset page number option to true, In theory this should reset every time the customer record changes. It sort of does but the problem exists in the M part of the Page N of M.
    Note: The Page N of M field is placed in the Group#1 Customer section that is repeated for every page.

    I've created an example using the Order entry database - I've attached the actual report below and a PDF export of the data
    In this example, watch the Page N of M as the page changes. You may notice that even though the Customer ID 2 should only have 19 pages, the M part of the Page N of M says it is 20. At page 20, the customer group value changes therefore it should reset the count back. It does this but again the M part is wrong.

    Order.pdf
    Order.dr
    Regards,
    Rol

  9. #9
    Join Date
    Feb 2009
    Location
    Adelaide, South Australia
    Posts
    2,863

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    I have a ‘tool’ that converts excel data into RDS data you can insert into your report if that helps.
    Marco Kuipers
    DataFlex Consultant
    28 IT Pty Ltd - DataFlex Specialist Consultancy
    DataFlex Channel Partner for Australia and Pacific region
    Adelaide, South Australia
    www.28it.com.au

  10. #10
    Join Date
    Feb 2009
    Location
    Houston, Tx
    Posts
    49

    Default Re: New page number on change of group no longer working. (DR 6.1.5.9607)

    Only if it imports the data into the studio.

    I already wrote a tool that enables DAC.EU to duplicate a problem from live data. My RDS logic is nearly all sub-classed (I didn't like the code from the Wizard), and there is a hot key even my customers can use that will flip a boolean to cause all RDS data and parameters to be intercepted and output to XML instead of to the report OCX. On the other end there is a simple program that will read the XML and execute the report - and I've sent it to DAC.EU via the HDE, source included. So all of my recent posts to the HDE have supplied data, in XML form, that reproduces any bug exactly within a few minutes of effort both by me and by DAC.EU.

    Response? They won't touch it. My first several tickets received no response whatsoever when I posted with data. Then DAC.Sales started bugging me over a subscription, which is truly a slap in the face after a year of substantial additional expense and dissatisfaction (vented at the DAC sales guy by phone). I reluctantly paid the subscription fee, then got a reply from DAC.EU on the HDE. They objected to my suggestion of an XML portal into the designer because the format uses too much memory, and stated plans for such a tool in JSON. I am comfortable with that, so now I (and my customers) simply wait. Everybody knows who Vincent is.

    I am certain that their debugging environment somehow requires the RDS data within the *.DR file, which currently is accomplished only by tedious manual entry. It's a problem that inhibits this developer's ability to test their product with real world data prior to release. We can look forward to a future version that will include a portal for importing data into the studio for debugging, and a release after that which will include all our bug fixes and finally surpass Crystal Reports in quality. In the meantime, keep paying those annual subscription fees to protect your investment in development time from being written off as a total loss. This may take a while.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •