Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Reports slow to generate

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Reports slow to generate

    I am still wrestling with our main business application that has been upgraded from V4.5.

    I have a pile of reports that worked quickly in V4.5 that now generate slowly (2sec. vs. 3 minutes). This group of reports gets its records from the current found set and does not have any filtering defined in the reports properties. When I query the set with fields from the parent table using QBF, and then preview the report, it opens immediately. When I query the set using QBF based on a field(s) in a child table, the query itself takes much longer (expected), but when I preview the report based on that query, it generates painfully slowly (takes longer than the query). It is almost as if the report is running the query/filter again and not actually using the found set. Is this expected in V10?

    I have another issue with V10 reports - I have a shipping ticket (report) that the dispatcher previews first before printing. The line items in the shipping ticket always display in preview, but many times when the report is printed to paper a blank sheet comes out with a page centered message that states "no records found". This has never happened in V4.5. Any ideas?

    Thanks.

    #2
    Re: Reports slow to generate

    Have you opened each of the Sets in Design mode and saved them without changing anything?
    I'm not sure that there is a straight transition between 4.5 and 10.5
    1 version - possiblly - but not this many.
    You may have to open all of the objects and resave them, then do a database Conpact.
    BACK IT ALL UP FIRST!
    See our Hybrid Option here;
    https://hybridapps.example-software.com/


    Apologies to anyone I haven't managed to upset yet.
    You are held in a queue and I will get to you soon.

    Comment


      #3
      Re: Reports slow to generate

      Ted - thanks for your reply and I will try your suggestions.

      There is something I have just noticed with V10. It appears that when you create a new set, the linking fields in the parent and the child MUST be of the same length. While this makes perfect sense, I know I have linking fields in some of my sets created in V4.5 that are not the same length. I wonder if that is an issue?

      Comment


        #4
        Re: Reports slow to generate

        Could well be. Alpha is hunting for a match.
        You could use an expression for the link to save changing the Tables, but I believe you will loose any Ref Integ. with an Expression.
        How many links have you got to change if you do it the "professional" way?

        PS. If you link on more than ONE field, the constraint goes away as an Expression is automatically built for you.
        See our Hybrid Option here;
        https://hybridapps.example-software.com/


        Apologies to anyone I haven't managed to upset yet.
        You are held in a queue and I will get to you soon.

        Comment


          #5
          Re: Reports slow to generate

          Ted - the application has 37 tables and 17 sets. The set that I am referring to now (shipping ticket set) that has the slow reports is the largest in the application with 11 tables. I will look through the joins and see how much trouble it will be to change the field sizes to match (I know at least one doesn't match).

          I know that good database design dictates that the data be well normalized which generally means breaking the data down into appropriate tables. What is starting to bother me is that when you need to bring that data back together, such as in the 11 table set in above, I am putting the complexity (and slowness in V10) back into my application that a less normalized structure would. I see here on the boards and in documents that have been written on simplifying your data structure - seems to me this in contrast to normalizing when you have to bring it back together in a set.

          Comment


            #6
            Re: Reports slow to generate

            Normalizing is much the same as wetting yourself in a dark suit.
            You get a nice warm feeling but noone notices.
            Keep it simple. Copy the Set you think you have problems with and run a parallel test.
            I think Al on the Forum has a comment about this in his signature.
            Normalization is good practice but Rationalisation is the key in my view.
            See our Hybrid Option here;
            https://hybridapps.example-software.com/


            Apologies to anyone I haven't managed to upset yet.
            You are held in a queue and I will get to you soon.

            Comment

            Working...
            X