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

Finding Records in an Embedded Browse

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

    Finding Records in an Embedded Browse

    I�m trying to figure out how to find a specific record in a child table that is displayed as an embedded browse on a parent form. Using a button to call an OnPush event I have found that the following syntax works to find the last, or first, record in the child table�s embedded browse:
    Code:
    Parentform: Browse.fetch_Last()
    or substitute fetch_first() to get the firstrecord.

    But what I really need is to find a specific record based using the value held by a variable. So what might be the magic syntax for finding a specific record? I�ve tried a number of possibilities but thus far haven't suceeded. Can some one steer me in the right direction?

    #2
    Re: Finding Records in an Embedded Browse

    Douglas,
    You have to have a specific field value that you can filter upon. First and Last does not offer uniqueness. I ALWAYS have a unique value for each and every record so I can filter for that record.
    what I really need is to find a specific record based using the value held by a variable.
    This has always worked for me from a form:

    topparent:tables:tablename.filter_expression = filter_Expression ... LIKE (ie: fieldname = "+quote(variable_value)
    topparent:tables:tablename.order_expression = ""
    topparent:tables:tablename..query()
    Last edited by Mike Wilson; 08-21-2009, 01:15 AM.
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

    Comment


      #3
      Re: Finding Records in an Embedded Browse

      Code:
      topparent:[B]browse1[/B].activate()
      topparent:browse1.fetch_first()
      while browse1:[B]column_title[/B].value<>[B]var->your_variable[/B]
      topparent:browse1.fetch_next()
      if browse1.mode_get()=2
      end
      end if
      end while

      Comment


        #4
        Re: Finding Records in an Embedded Browse

        Forgive me for butting in to your thread, but I like the idea of a button which goes to the latest record - as opposed to having to scroll down each time. So I have added a button and copied your code e.g. "Parentform: Browse.fetch_Last()" but nothing happens. Please excuse my ignorance but can you please advise on the actual syntax I should be using.
        Kind regards,
        Larry

        Comment


          #5
          Re: Finding Records in an Embedded Browse

          Larry, just tried it and it works... but make sure you get your syntax right. I don't know if it's just mis-typed here but your code...

          Originally posted by Larry Gordon View Post
          Parentform: Browse.fetch_Last()
          should produce an error. You have a space after the ":"... and unless you renamed your browse it's usually a numbered browse when it's dropped on a form... e.g.

          parentform:browse2.Fetch_Last()

          Recheck - that may be it.

          Comment


            #6
            Re: Finding Records in an Embedded Browse

            David, thanks for the prompt reply - you are of course quite correct; now works a treat. Many thanks for your help.

            Comment


              #7
              Re: Finding Records in an Embedded Browse

              Larry. Glad you fixed your problem. Still working on mine. You do know that Fetch_Last does not retrieve the latest record in a browse unless Recno() is the index on the browse table when you execute the fetch. If the index is something else what gets fetched will be the last record in that index's sequence and that almost always won't be the latest record. Likewise with fetch_first not getting the first record added, but the first record in whatever index or sort is active.

              A5 apparently provides no built-in, automatic non-procedural mechanism for placing the embedded browse focus onto the record that was last added by use of a 'companion form for an embedded browse'. After adding new records to the child table upon returning to the parent form with the embedded browse A5 automatically places focus onto the last record of the embedded browse according to whatever primary indexing/sort sequence is in use. I don�t like that because what I want to see is the last child record that was added along with its fields that are displayed on the parent form. I can easily accomplish this objective if Recno() is the sort order for the embedded browse and I use fetch_last(). But Recno() as a primary index for an embedded browse that end users will be visually navigating through isn�t particularly meaningful. ID or Last_Name fields would be much better as an index for the browse. The suggestions from Mike and Gabe are sort of workable, but with attendant baggage. Using a filter and query based on a unique value results in the embedded browse being limited to showing the one unique record. Other records in the child table can�t be seen until the index/sort is unique filter query is removed or reset. Using fetch_next to sequentially read records from the top of the table until a matching value is found is inefficient particularly if the table is large. Try it on a large table. Plus see the visual appearance of the browse as its being done. Not very pleasing.

              So I've attached a sample file to illustrate what I�m looking to accomplish. In the sample the main form is bound to a set comprised of two tables: parent table �Companies� and child table �Contacts�, linked 1:Many on field Company ID. The form contains an embedded browse to navigate through the parent �Company� records and a button to call a form for adding new company records along with some simple Xbasic code that will place focus onto the last, new company record using the company name from the new record key value to locate on. Works just the way want it.

              There is also an embedded browse to display records from the child table �Contacts� and fields from the Contacts record in focus in the embedded browse are also displayed on the parent form. A button calls a �companion form for an embedded browse� in order to add new records to the �Contacts� table. I have yet to figure out how to duplicate the efficiency demonstrated for the parent table browse with the child table embedded browse - unless I use Recno() to do so. Ideally I want the primary index/sort on the child browse to be based on 'Last_name' or 'ID' to be used to locate the last record when coming back from the companion form. Unfortunately the simple method used in the parent table embedded browse doesn�t work for a child table embedded browse. I�m still stumped how to do it. Don�t see why this should be such a difficult challenge.

              Comment


                #8
                Re: Finding Records in an Embedded Browse

                Douglas, see attached.

                Added an inline action to your button.
                The basics of it is - get a pointer to the table that the browse is based on - go to the new record based on its recno() - then resynch the browse to the table. The new record's recno() is assumed to be the largest recno() value for the particular Co_id. That is what the tablemax() function is doing.

                Two possible problems with this approach can arise in a multi user or networked application:
                If the user saves changes but delays in closing the Add_contact form and a second user adds a contact to the same company and finishes first then user1 would end up on user2's new record.
                Using tablemax to get the recno means opening a new instance of the table and over a network would add to the network load and possible application speed. I would say it is minimal but theoretically there would be some.

                In the Add contact 2 button I have used a global variable to grab the recno() in the onsave of the Add Contact form. Then used that variable instead of the tablemax function.

                In the Add Contact 3 button I have used a different approach to open the form, namely the form.viewlinked() function. I suspect that this function is used within the action to open a companion form for an embedded browse but it is only that, a suspicion. Any way using this approach we can grab the recno() directly from the form before we close it. (using frm.current_record() )


                NOTE: Fetch_goto() does not rely on a specific index as fetch_find() or find() does. It also leaves the current index in place. The only thing is, it is a table level function so if used in a layout the layout needs to be resynched.

                Holler if you have questions. Although lately I seem to have less time to be a nuisance around here.


                PS The reason my zip is much smaller than yours is that I compacted the database first. This clears out all of the previous design edits you have done to the application.
                Last edited by Tim Kiebert; 08-23-2009, 12:11 AM. Reason: additional note
                Tim Kiebert
                Eagle Creek Citrus
                A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                Comment


                  #9
                  Re: Finding Records in an Embedded Browse

                  Douglas, I'm only a new boy at this, but would a new set help? I find myself creating new sets on a regular basis. I then define the order of the records there, rather than the button script etc. I know from my Clarion days in the 80's that the more indexes you had, the slower it ran - 5 was a sensible ceiling - but this doesn't appear to apply to Alpha. The main reason I went this route was I got fed up with the records re-ordering themselves each time I closed a form and returned to a browse.

                  Comment


                    #10
                    Re: Finding Records in an Embedded Browse

                    Thanks guys (Mike, Gabe, and Tim) for the suggestions. I think Tim has provided two slightly different approaches, each which would from my quick testing seem to exactly meet my objective. Thanks Tim I really appreciate the jump start you've provided. Your second solution seems to be quite direct and efficient and I'm thinking that I will likely adopt that approach.

                    Comment


                      #11
                      Re: Finding Records in an Embedded Browse

                      Larry I�m probably not the best guy to ask about Dbase indexes overhead as my only experience using A5 Xbase/Dbase has been since I picked up A5. Thus far I've been more focused on slogging through the process of learning the A5 design paradigm and not so much on the nitty gritty details of Xbase/Dbase. One huge strength of A5 however is this board with the participation of so many extremely knowledgeable A5 developers who are so gracious in their willingness to take pity on us A5 rookies.

                      A5 Xbase permits 40 indexes per table, maximum of 240 characters per index, with the number of fields participating in a compound index restricted only by the max index length and length of the key expression. My presumption is that both the number and complexity of indexes that are defined for a table can significantly, negatively impact the speed of writing records as well as the size of the index tables. What the magic numbers would be to avoid inducing intolerable performance I haven't a clue yet. I just try to follow the practice of keeping indexes as few and lean as possible to accomplish my application's internally defined processing requirements along with what I can reasonably anticipate end users may want to do on their own with any regularity.

                      In A5 indexes are physically set in the design phase of each table. When designing sets as well as forms A5 provides the ability to assign sort fields but in so doing does not distinguish whether they have been explicitly defined as indexes. That makes it incumbent on the developer to know whether a field being used as a sort for a set or form is in fact an index. I would expect un-indexed sorts and filters to be quite inefficient for large tables so I'm thinking if you apply a sort in either a set or form design you probably want to make sure that the field chosen has been defined as an index. I'm not sure if there are any inherent benefits (except maybe programming efficiency) between defining sorts in the set design vs defining them in the forms designs that are bound to the set. Others may have more to offer on this.

                      Comment

                      Working...
                      X