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

Memo fields in browses

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

    Memo fields in browses

    I have a browse (I have used both embedded and named defined browses) with a memo field. When the user tries to view or edit the memo field, they occasionally are able to, but most of the time, they get into the same memo each time.

    From a previous post, I received a hint to pull a browse field off to the side, and my users will be testing this next week, but I'd still like a better fix around my problem. Could it be an indexing problem? Is there something special I should do to my browse to handle memo fields in a better way?

    Thanks much!

    #2
    RE: Memo fields in browses

    Hi Valerie,

    I tried to use memo fields in a browse but didn't like the way they had to be opened. It appears that memo fields are not all that stable hence the suggestion you are about to try. It has also been suggested that a separate table be established to hold the memo fields.

    I ended up switching to a character field set to the max # of characters (255). Unless you have a need to go beyond 255 characters, my suggestion is to switch to the character field. If you do, don't forget to set the character length as soon as you change from memo to character.

    kenn
    TYVM :) kenn

    Knowing what you can achieve will not become reality until you imagine and explore.

    Comment


      #3
      RE: Memo fields in browses

      Sounds like something else is going on there. Could you be more specific? Are you talking about regular memo fields or RTF? In a set, on a conditional object? Some combinations of these may cause problems. However, I disagree with Ken's assessment. I use memo fields quite a bit without any problems. But I do agree, if you don't need more than 255 characters per field, stick with a non-memo field.
      Peter
      AlphaBase Solutions, LLC

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


      Comment


        #4
        RE: Memo fields in browses

        Hi Peter,

        The only thing I don't like about the memo fields is the extra step it takes to get into them. I personally didn't have any problems and many have not as well. However, for some reason, many have had problems and there has been discussions and suggestions on this issue. Valerie had not received a response so I thought I'd respond.

        Hopefully, V5 will correct the issue as I really like the RTF memo fields.

        kenn
        TYVM :) kenn

        Knowing what you can achieve will not become reality until you imagine and explore.

        Comment


          #5
          RE: Memo fields in browses

          The memo in question is not an RTF, and there is the possible need for more than 255 characters.

          The memo field is a comment associated with an entry date, an entry person, and (optionally) a next action date.

          The table that these things reside in is a grandchild table (I thought this could be part of the problem). The top table is clients with a one-to-many link to contracts (the link, clientnum is generated by A5). Contracts are then in turn linked one-to-many to the log table (the link here is the company filenum). So, Mr. Smith may have 3 contracts, and each contract has an independent log.

          In my testing, the field out of the browse, on the form seemed to work. It also enabled the user to use F2 to get into it.

          However, if there are further problems, I may have to restrict them to 255 characters (not completely impossible).

          Thanks

          Comment


            #6
            RE: Memo fields in browses

            "The table that these things reside in is a grandchild table."

            I agree that this may be significant. I bet your browse is based on the set. If so, there will be a separate record (line) for each parent-child-grandchild combination which could be confusing.

            If you could set things up on a form with the grandchild records in an embedded browse it might be clearer to users exactly what they were looking at.

            Alternatively, the browse could be based on the grandchild table rather than the set.

            Bill
            Bill Hanigsberg

            Comment


              #7
              RE: Memo fields in browses

              Bill has a good point. You may be viewing virtual grandchild records, thus the duplication. You might try three distint embedded browses - 1)parent; 2)child; 3)grandchild. With a complex set (many to many), you may have to take care on how users view and access data. I strongly feel there is nothing unstable about regular memo fields.
              Peter
              AlphaBase Solutions, LLC

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


              Comment


                #8
                RE: Memo fields in browses

                I have handled the duplication stuff with a tabbed form.

                On tab one the user picks the client, with a alphabet button like in the invoice example.
                On tab two, the client info can be viewed and changed, and a browse allows you to pick a contract from all of that client's contracts.
                On tab three, the contract info can be viewed and changed.
                On tab four, the log info (for that contract alone) can be viewed and changed.

                I have thought about making each of these tabbed areas its own form and, using some variables pass filtering information to each form. But it seems to me that opening multiple forms and filtering data would be slower than a single form.

                Thoughts???

                Comment


                  #9
                  RE: Memo fields in browses

                  Oops -- didn't completely answer your question --

                  The browse is only based on the table, but the whole form is based on the set.

                  Comment


                    #10
                    RE: Memo fields in browses

                    I'm not sure I'm following you. Are you saing you *olved* our problem by breaking up the data on a tabbed oject?

                    Yes, It is slower using multiple forms. I have the same problem myself. I try to keep everything on one form to the extent possible, but have to break them up occasionally. e.g. I have a client-contacts set, and for years had them on one tabbed object. Finally, I split it up because the child subform was sometimes erratic when entering data. Now I restrict the subform to view mode only, and enter new contacts via a popup dialog form. I'm not completely happy with the results and looking forward to v.5 to fix some bugs. We'll see...
                    Peter
                    AlphaBase Solutions, LLC

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


                    Comment


                      #11
                      RE: Memo fields in browses

                      I mean "*solved* your problem..."?
                      Peter
                      AlphaBase Solutions, LLC

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


                      Comment


                        #12
                        RE: Memo fields in browses

                        Valerie,

                        FWIW, I have a set with 9 child tables and growing. The main form contains fields from the parent table and along with a tabbed form. Each tab contains fields, or a form or a browse (w/calc fields placed to the side of the browse) or a combination from each child table. All works well with no side effects or slow actions. At this point, there is not a lot of data as this is under development so once the data gets transferred, perhaps I might experience a problem or two. I hope not. If I do, Access will be one up!

                        kenn
                        TYVM :) kenn

                        Knowing what you can achieve will not become reality until you imagine and explore.

                        Comment

                        Working...
                        X