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

overhead calculated vs conditional fields

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

  • overhead calculated vs conditional fields

    I am wondering if anyone has an idea if there is a difference between the overhead of having a calculated field versus a conditional field. Normally I have not had to worry about this but am creating a multi-use report that uses both currently and can see where it can get out of hand rather quickly. I know a form's browse can come to almost a stand-still with too many calculated fields so am wary of them....but have not the experience with having a lot of conditional fields. They seem so similar that it may very well be the same overhead but thought I'd ask!! :-)
    Mike
    __________________________________________
    It is only when we forget all our learning that we begin to know.
    It's not what you look at that matters, it's what you see.
    Henry David Thoreau
    __________________________________________




  • #2
    Re: overhead calculated vs conditional fields

    I'm not familiar with the term conditional field. Could you direct me to some explanation?
    There can be only one.

    Comment


    • #3
      Re: overhead calculated vs conditional fields

      Sorry Stan. I am talking about a conditional object in which you can place a field.
      Mike
      __________________________________________
      It is only when we forget all our learning that we begin to know.
      It's not what you look at that matters, it's what you see.
      Henry David Thoreau
      __________________________________________



      Comment


      • #4
        Re: overhead calculated vs conditional fields

        Hi Mike,
        I would think having 'a' calc field vs 'a' condition would not make much difference. But you said 'many' without qualifying how many that is, or how complex your conditions are. More info please!
        Robin

        Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

        Comment


        • #5
          Re: overhead calculated vs conditional fields

          On the previous Browse I mentioned that slowed down to a crawl where there was about a 2 second time lapse between row selections I had maybe 30 calculations

          What I am currently working on is a report that right now has over 100 calculated fields, and about 30 conditional objects (each with an average of 4 conditions within--so about 120 conditions).

          There are about 30 more conditional objects to put in....this is where my question originates.
          The choice is to have more conditions within each condition with less calculated fields or less conditions with more calculated fields.

          In addition, I have added more fields in the report table that utilizes field rule calculations which eliminated quite a few calculated fields....but have about 600 fields now and although the limit is over a 1000, I really don't want to go there! :-)

          If there is no difference in overhead, I will do the most simple...if there is I will do whatever is best. My goal always is to make something as bulletproof as possible and the more overhead you have the more tendency it may break and at the very least cause time lag.


          EDIT: I try not to make the calcs complex in that I avoid placing a calc within a calc as I have seen that have issues. The most complex is a simple if(,if(,if,,))) statement.

          Also, whether on a form, browse, report or whatever my concern is the overhead. Each layout seems to have a different amount of calculations that cause issue...a report seems the most forgiving.

          EDIT: I have not dealt with this many conditions and do not know if they will cause the same problems too many calculations can.
          Last edited by MikeC; 04-11-2017, 06:49 PM.
          Mike
          __________________________________________
          It is only when we forget all our learning that we begin to know.
          It's not what you look at that matters, it's what you see.
          Henry David Thoreau
          __________________________________________



          Comment


          • #6
            Re: overhead calculated vs conditional fields

            reports with 40+ calc fields,50+ objects, hundreds of fields on the reports, tons of color equations, and no lag here, but that also has to do with how complex everything is.
            Dave Mason
            dave@aldadesktop.com
            Skype is dave.mason46

            Comment


            • #7
              Re: overhead calculated vs conditional fields

              Thanks for the input. Conditional objects seem to be more or less a filter as I now see it and so am inclined now to think that they won't be an issue. Except as is said, anything taken to the extreme can cause problems. I may be able to call another report instead of having to deal with all of Conditional Objects and Calculations that would be required on this single one. Regardless I will post back with any issues I find regarding this.
              Mike
              __________________________________________
              It is only when we forget all our learning that we begin to know.
              It's not what you look at that matters, it's what you see.
              Henry David Thoreau
              __________________________________________



              Comment


              • #8
                Re: overhead calculated vs conditional fields

                Hi Mike,

                I will try to avoid conditional objects if possible. In addition, I will to try to avoid calculated fields in reports as well. Do all your calculations in the Stored Procedure level and placed them in the report or use Computed fields in table as well. It is much faster this way. I will assume that you are using database like MS SQL Or MySQL.

                Here is an example of code that can avoid 4 conditions in the conditional object. You basically place this field: ItemDesc instead of the conditional object with 4 fields.

                Code:
                ItemDesc = IIF(VendorNotesFlag=1,VendorNotes,IIF(SortOrderAcct=2,ppItemDescription,IIF(SortOrderAcct=3,AccountsDesc,IIF(SortOrderAcct=4,PoDescrpToVendor,""))))
                Regards,

                Doron
                The Farber Consulting Group, Inc.

                Main Web Site: http://www.dFarber.com
                Avis Car Rental Software
                See additional Videos : http://dfarber.com/custom-software-d...ulting-videos/

                Comment


                • #9
                  Re: overhead calculated vs conditional fields

                  Mike,
                  Could any of these calcs/ conditions be resolved by using temp tables for your report? Do you have a screenshot of what you have so far?
                  Robin

                  Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

                  Comment


                  • #10
                    Re: overhead calculated vs conditional fields

                    The way I create reports is to have a table that has all the records the report requires(call it a "Collection table)...generally no sets and such. A few reasons for doing so. To export to Excel is one as the Amyuni print driver will not export to Excel from the report and be able to format it correctly(not easily at least!) but exporting a table will. Also I use a table such as this to create files for EDI files which can be CSV or any other text format determined by whatever the Reporting agency requires. For a report it makes it unnecessary to have a set as summary, append, post, or update operations use the Collection table as the destination which works for even totally unrelated tables(so no creation of creative links). I also store the data for each year in its own table for future use....you see, much of my reporting is done by getting information from QuickBooks and a Refresh of data can be very time consuming and storing the data eliminates this issue even on the current year.

                    So far I have not had any issues with the report....the reason for posting was to see if anyone knew of any inherent issues with having a lot of conditional objects and calculations in a layout especially as it pertains to a report as I am not done adding them.

                    So I don't have a problem (YET !) that needs fixing....just trying to avoid that if possible is all.
                    Mike
                    __________________________________________
                    It is only when we forget all our learning that we begin to know.
                    It's not what you look at that matters, it's what you see.
                    Henry David Thoreau
                    __________________________________________



                    Comment


                    • #11
                      Re: overhead calculated vs conditional fields

                      Like Mike
                      Been using the temp table for years with my upslogs app. I have to print very long bank contracts and use Crystal reports to do that due to AA's report writer limitations. This works really great.
                      The temp table is actually named and is constant, but is emptied after a print and populated just prior to print. Other reports needed are built on the print table so I can keep the reports current.
                      Dave Mason
                      dave@aldadesktop.com
                      Skype is dave.mason46

                      Comment


                      • #12
                        Re: overhead calculated vs conditional fields

                        Dave,
                        I don't think Mike is using a temp table but something along the lines of his own 'mapped' table to make a flattened version of his set tables.
                        Robin

                        Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

                        Comment


                        • #13
                          Re: overhead calculated vs conditional fields

                          Robin,
                          What Dave is doing is exactly how I use the table...He calls it a Temp table, I call it a Collection table, and others may call it a Report table, etc. No sets are used for my reports for the most part--just for forms mainly.


                          Dave,
                          Off topic but am curious on your statement of "...report writer limitations...". The main limitation I have found is the charting ease and capabilities which is the only thing I can see Crystal Reports being much better at. I have yet to have a client ask for a report that I cannot do with Alpha.
                          Mike
                          __________________________________________
                          It is only when we forget all our learning that we begin to know.
                          It's not what you look at that matters, it's what you see.
                          Henry David Thoreau
                          __________________________________________



                          Comment


                          • #14
                            Re: overhead calculated vs conditional fields

                            I can easily print a 40 inch contract with no breaks using CR, but not with AA"s writer.
                            I have one that is extra wide and 48" long I have to print. All of these are 90% numbers with a little bit of text and are pre-printed contracts and 9 layers thick. I use a dot matrix printer for these
                            (Okidata 320 or 321)
                            Dave Mason
                            dave@aldadesktop.com
                            Skype is dave.mason46

                            Comment


                            • #15
                              Re: overhead calculated vs conditional fields

                              Makes sense Dave. So not entirely a report writer issue though as pdf can be have multiple pages printed as one sheet (not the Amyuni pdf print driver though)...even my old HP 5100 Deskjet can print up to 30 inches long as one page (but only 8.5 inches wide). I have not tried it and there may be other issues involved such as a gap between pages even with using zero margins.
                              Mike
                              __________________________________________
                              It is only when we forget all our learning that we begin to know.
                              It's not what you look at that matters, it's what you see.
                              Henry David Thoreau
                              __________________________________________



                              Comment

                              Working...
                              X