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

Report: Memo Fields Print VERY Slowly

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

    Report: Memo Fields Print VERY Slowly

    I have designed a report that prints a rich text (RT) field. The RT field contains 40 calculated fields (CF). The CFs are simple 'if' expressions eg:
    if(VAL(Ag)>Interpcassen->Aghilm,Interpcassen->Aghimemo,"")
    where Interpcassen->Aghimemo refers to a memo field in the set that the report is based on.
    The report works OK... except that it is VERY slow; ~15 minutes on a Pentium II 700 Mz, to print one report (a single record in the parent table).
    The situation gets worse as the sise of the memo fields grows. A typical report has grown from ~8 pages, (requiring 5 or 6 minutes), to the current size of ~18 pages, (requiring 15 - 20 minutes)
    I have scanned this data base and found quite a few references to printing memo fields but either I did not understand or there is nothing dealing with this specific problem.
    Can anyone offer some suggestions?
    David Boomer

    #2
    RE: Report: Memo Fields Print VERY Slowly

    Is it possible to verify that the memo field has not been corrupted?
    Bill Hanigsberg

    Comment


      #3
      RE: Report: Memo Fields Print VERY Slowly

      How would I check?
      As far as I can tell they are ok... when I view them in a form they appear ok.

      Comment


        #4
        RE: Report: Memo Fields Print VERY Slowly

        Do you have a filter set in the report? Filters can slow the report down to a crawl.
        Peter
        AlphaBase Solutions, LLC

        [email protected]
        https://www.alphabasesolutions.com


        Comment


          #5
          RE: Report: Memo Fields Print VERY Slowly

          Thanks for the suggestion... but I do not have any filters in the report per se. The report IS set up to print currently selected records but it prints slowly with or without a query.
          It seems to be related to the total (or individual) size of the memo fields.

          Comment


            #6
            RE: Report: Memo Fields Print VERY Slowly

            Q1: Is this a set report or single table?
            Q2: Is the memo in the detail section or elsewhere?

            Peter
            Peter
            AlphaBase Solutions, LLC

            [email protected]
            https://www.alphabasesolutions.com


            Comment


              #7
              RE: Report: Memo Fields Print VERY Slowly

              Thanks for your help Peter. I realy appreciate it.
              The report is based on a set 6 child tables are joined (directly & indirectly) to a parent. The relationships are all 1:1.
              The memo fields are in a child table. I wonder if Lookup expressions would be more efficient?
              Db

              Comment


                #8
                RE: Report: Memo Fields Print VERY Slowly

                David,

                Remember what goes on when you build a set. If there are 6 distinct child records for a set, and the memo is on the last child, then you will look through 6 composit records, all with everything in them before getting to your specific required record.

                Now, is it possible to build the report based on a smaller set, say with only one or 2 child records? This has helped us greatly with our reports. You will dramatically reduce the amount of data that you are looking at, especially since you are using calculated fields. Calculated fields are evaluated for EVERY detail record. If you don't need information from every child, then just build a "report" set using only the necessary tables. If you only need one or two pieces of information from some of the child tables, then look it up instead of attaching the whole record.

                Hope this helps,

                Tom

                Comment


                  #9
                  RE: Report: Memo Fields Print VERY Slowly

                  David,

                  You didn't quite answer my question - are the memo fields in the detail section of the report? But, seeing as you have 6 child tables, that might explain it. You might try putting the child records each in their own subreport. You can crate a subreport for each child table in the detail section. This may dramatically speed up the report. I used to use child-filters and those reports took forever. When I discovered the secret of subreports and filtering only there, the reports printed nearly instantaneous!

                  Peter
                  Peter
                  AlphaBase Solutions, LLC

                  [email protected]
                  https://www.alphabasesolutions.com


                  Comment


                    #10
                    RE: Report: Memo Fields Print VERY Slowly

                    Thanks for the suggestion... unfortunately I could not improve report times... in fact they got worse!
                    I even tried creating a report based on the table containing the memo fields alone.

                    I have observed that the MemoTable.ddm file has grown from about 200Kb to 4MB!! even though I have not added much in the way of content. I tried 'emptying' the table and packing but the DDM file is still there!

                    Comment


                      #11
                      RE: Report: Memo Fields Print VERY Slowly

                      All .dd* files are dictionary files, they contain no data. Try doing a database compact and they should be reduced. If you've never done a database compact before, you might want to back up the entire application.

                      Comment


                        #12
                        RE: Report: Memo Fields Print VERY Slowly

                        It looks like you have a corrupt memo file. Check in the coe archive for a routine to fix this. Melvin Davidson wrote it. It is listed under "memo File Repair scripts". The routine is wonderful!

                        Tom

                        Comment


                          #13
                          RE: Report: Memo Fields Print VERY Slowly

                          Thanks I will do this.
                          I think I am closing in on the problem/solution.
                          The memo fields (50 of them) are located in a RichText field in the detail section of the report.
                          When I remove them from the RichText field and place them directly on the layout the report prints VERY fast.
                          The problem appears to be related to the size of the memo fields vis a vis the capability of the RichText field. The combined size of the fields often results in a 20 page report.
                          The reason may still be a corrupted memo file. I will try the memo fix & report back.
                          Thanks

                          Comment


                            #14
                            RE: Report: Memo Fields Print VERY Slowly

                            I tried the repair script... alas it is for one memo field at at time and I have ~150 of them in the table!! In addition, the script did horible things to my memo table... had to restore from *.zip.
                            The move of the fields from the RichText field allowed the report to run VERY fast... but alas it looks VERY crappy!! I need the rich text capability to shrink & grow the individual fields otherwise the report is unusable. But, when I place the fields in a RichText field the report again runs SLOWLY!!!
                            Help!!! This has GOT to get fixed because a business is being built solely on this report! The report is used to perform a rather intricate analysis & interpretation of the output of a mass spectrometer. The results are reported to doctors and they rely on fast turn-around to treat their patients.
                            David

                            Comment


                              #15
                              RE: Report: Memo Fields Print VERY Slowly

                              memo fields and others can be set to allow shrink. Is there a way to put only the non-memo fields in the RTF, if that is what you need to do?
                              Peter
                              AlphaBase Solutions, LLC

                              [email protected]
                              https://www.alphabasesolutions.com


                              Comment

                              Working...
                              X