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
Devcon 2020 Goes Virtual! LEARN MORE >

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

index behavior in browse vs form

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    index behavior in browse vs form

    I have created a browse based on a set. An index was created in the set for the field "status". A filter/query was created "active" that filters the status to active records. There are approximately 15,000 records and the results after an "active" filter are generally about 20. When the filter is run on the browse it takes about 5-6 seconds to filter and you can watch the green status bar in the lower left filter through the records. It is behaving as if the index is not working.

    However, when I place the the exact same browse as an embedded browse on a form and run the identical "active" filter, the results appear in just over 1 second. Why would an index work in an embedded browse on a form and not in the stand alone browse? This is being tested on a shadow copy over a network.

    You may ask, why not just run the browse in the form? I agree, but that creates a new issue. Once my filter "active" is filtered to the approximate 20 records, I will go to change a field (generally a check box) and once the record is saved it will move that record up to the top of the browse. In other words I want the results list to remain the same when I edit them within the browse. I do not want Alpha to move my recently changed/saved record to the top of the browse in essence hiding all records before it. This behavior does not happen in a stand alone browse, only when it is in a form.

    There is perhaps an easy fix or it is a bug. I'm using the latest build of version 9, but this behavior is the same on previous builds and versions.

    Travis
    Tags: None
    #2
    Re: index behavior in browse vs form

    Let's restate the question: Is there any reason why an index will not work in a browse, but will work with the same browse in a form?

    Comment

      #3
      Re: index behavior in browse vs form

      How about posting a sample database that illustrates the problem? Indexes are not created "in sets" as you say, but are bound to tables. Whether the table is primary or a linked child table can affect performance. If you're querying the child in a set based browse a lot depends on how you've defined the query. For instance, are you filtering only the records that are linked to the current parent table record? Are you filtering all child table records regardless of whether they are linked to the current parent table record? Your narrative fails to give sufficient details because there are many different ways you could have set this up.

      Comment

        #4
        Re: index behavior in browse vs form

        Tom, thank you for responding. I will work at posting a sample database, but let me first give some further information that might help explain the situation. The parent table has a field "status" which is indexed. There are 7 child tables in the set. The browse has approx 15 columns with mostly fields from the parent table and a few from the child tables. The filter is based only on the parent table field "status". Again the problem being a browse built on this set does not use the index, but when I embed this same browse on a form the index is recognized. The speed over the network with a shadow is 5-6 seconds(browse) vs. 1 second(form). Logically it seems that the speed should be the same on whether you use a browse or a form all things else being equal. Bug? or I'm I missing something.

        Comment

          #5
          Re: index behavior in browse vs form

          You may be missing something. It may be a bug we can corroborate. There are further questions which occur to me which might explain what you're seeing. However, at the risk of sounding petulant (sp?) I'm not especially interested in playing twenty questions with you just to get a good understanding of the specifics of the situation you are confronting. Will be happy to take a good look once a sample is furnished. The behavior you describe sounds odd and wrong. But the basic question can't be answered without a working model to explore and study. At least not by me. Maybe others will chime in with a more helpful answer for you. -- tom

          Comment

            #6
            Re: index behavior in browse vs form

            Index behavior in form vs browse.

            An index called (status) created in the table "load" is the primary table in a set called "load detail". When creating a browse with the "load detail" set, the index is not be utilized and it takes approx 6 seconds over a network with a shadow database to filter 15,500 records to approximately 20 records. However if you embed the same browse in a form, the index is utilized and the same filter performs in about 1 second. Any reason why the browse would not be seeing the index, but when place on a form it does?

            Steps:

            1. open application (preferrably on a network where the speed issue is more noticable.
            2. the "test active loads" form will open automatically.
            3. all loads 1- 15,500 will be in the list.
            4. click on the "script" button to perform a saved query (22 qr active loads).
            5. It will take approx 1 second to filter down to about 20 records in available, booked, heavy, intransit status.

            6. from browses tab in control panel, open the "All Load Browse"
            7. all loads 1- 15,500 will be in the list.
            7. double click any row to start the saved query (22 qr active loads).
            8. It will take approx 6 seconds to filter down to about 20 records in available, booked, heavy, intransit status.

            Again this is a big speed difference between running a filter in the form vs the browse.

            Comment

              #7
              Re: index behavior in browse vs form

              Travis, I don't have a LAN connection that's convenient tonight. Do you see any speed difference if you double click a row on the browse object you've embedded in your form? Since you're embedded the named browse into your form the onRowDblClk event will still work. How does it perform?

              Maybe it's me... but it seems odd to base the saved browse layout on the same complex set you are using for your form. When you place the named browse layout inside the form I wonder if you're opening two instances of the same set? Haven't seen this done before. A more typical design would base the saved browse layout on one of the child tables, and then embed that layout in the form. At least that's been my experience.

              In any case, running the saved query from the OnRowDblClk event of the saved browse layout occurs instantaneously on my local stand alone machine. I don't see any speed difference, but then I'm not using a LAN to connect to my data. If you see the same thing running locally, doesn't that suggest that there's something different in how the data is being moved over the network? I wouldn't think this to be an INDEXing issue. Maybe the way Alpha preloads data in forms is different than how it does it when opening a browse layout ? The form based script button seems to run without fetching any additional data, but then this is hard to detect without a LAN.

              -- tom
              Last edited by Tom Cone Jr; 09-18-2008, 10:56 PM.

              Comment

                #8
                Re: index behavior in browse vs form

                Travis, this morning using a LAN that connects to the "server" over a slow wireless connection, I saw a marked difference.

                a) running the saved query from the "script" button took about 3 seconds

                b) running the saved query from the onRowDblClk event of the browse object in the form took about twice as long

                c) running the saved query from the onRowDblClk event of the named browse layout (outside of the form) took about 10x longer.

                This seems odd and wrong to me. Suggest you submit a formal bug report using the Help menu in Alpha Five. Send them the example you posted here, with instructions. Let us know what response you get.

                I'm using Build 1724 on XP SP3 boxes.

                -- tom

                Comment

                  #9
                  Re: index behavior in browse vs form

                  Tom, thanks for confirming a possible bug. I will let you know their response. Travis

                  Comment

                  Previous template Next
                  Working...
                  X