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

another mystery

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

    another mystery

    hi again all!

    i am encountering a strange lookup problem. it occurs only about once in 20 entries.

    the set is a one to many with s_p_head as the parent and s_p_detail as the child. the linking field is receipt_num (c 10). creating a new record in the s_p_head then opens a browse of s_p_detail and the first field is an invoice_num lookup by invoice_num (c 10) in the table sale_head. the only filter is that the sale_head must have a balance of >.001 . out of the last 40 entries i have had the following error message twice:

    cannot create lookup.
    lookup definition incomplete or invalid.
    not an open index.

    if i acknowledge the error (hitting enter) and advance to the next field in the browse (hitting tab), then return to the lookup field (shift tab) the lookup works again.

    i've compacted and checked my file sizes .. all looks ok. what have i done (or not done) that would lead to such an unpredictable happening.

    thanks in advance.

    top of the season to all!!!!

    regards,

    ed

    #2
    RE: another mystery

    hi:

    i think that i may have found the problem. in the lookup there are a number of fields that get filled in and a few that get posted. in making some changes to the structure of the s_p_detail table i deleted a field called balance as it was no longer required. the lookup was trying to post to a non-existent field. hope this was it!!

    regards,

    ed

    Comment


      #3
      RE: another mystery

      Ed,

      I hope you've found the trouble spot. I think there's still an unresolved issue involving filtered table lookups...

      -- tom

      Comment


        #4
        RE: another mystery

        hi tom:

        well ... just when you though it was safe to go back in the water ....

        no, indeed that (missing field) was not the problem. i'm using 4.03 build 230 and never encountered this before.
        are there any work-arounds? at the current time it is a minor "painus en drainus" entering records but my concern is are there going to be any of those nasty corruption or bloating issues rise up as a result of the anomaly?

        thanks tom,

        top of the season to you sir!

        ed

        Comment


          #5
          RE: another mystery

          hi:

          i was changing the filter to display any negative balances by using balance!=0 instead of >.001 (balance is n,10,2 so rounding errors should not be a problem) and realized that it is actually a multiple filter (on the cust_id as well).

          has this been the issue?


          balance!=0 .and.Cust_Id=S_P_Head->Cust_Id

          thanks,

          ed

          Comment


            #6
            RE: another mystery

            Ed,

            I don't recall a fix for the problem with filtered table lookups. You might search the board. If you find that something's been released or a work around is available let me know.

            In my own work I do not filter the table lookups, but I do set the display order to match a convenient index so the user can quickly 'find' the desired record in the lookup list.

            -- tom

            Comment


              #7
              RE: another mystery

              Ed and Tom,

              There is indeed a known bug with filtered lookups. After anywhere from 8 to 15 lookups, you will get the message you see. The good news is that Alpha has tested a solution, A5v4.5 build 267. Unfortunately, this build has not been released. I got to test this build in the full version and it works fine with filtered lookups. As far I as know, a runtime version was never developed. If the problem is a show stopper, you may want to contact Alpha directly and see if this build is available, even as a Beta.

              Jerry

              Comment


                #8
                RE: another mystery

                hi jerry:

                thanks for your reply!

                i'm going to try a couple of things. first i'm wondering if a query has been applied to the table i'm looking up that would cause this problem. second i will try adding some code to the form that will filter the lookup table before entering the child browse. also i saw a recent post by finian regarding global variables that may be applicable.


                i'm commited to staying with v4.03 build 230 as i have unlimited runtime license and several installed applications.

                thanks again to all for your help. if i do get a workaround i'll post it.

                regards,

                ed

                Comment


                  #9
                  RE: another mystery

                  Ed,

                  I have the same problem with runtime limitations, and since no updated runtime build is available, the lookup problem still exists. Unfortunately, I have tried a number of workarounds (I already use a global variable for the lookup filter) and only one worked, and it is a very clumsy one. If you exit the form between saves, the next lookup is fine. On one app, I close the form on save, show a momentary dummy form, and then reopen the original form on the saved record. The process takes about a second and is not too annoying to the user. The reason I do this has nothing to due with lookups, but that is a bonus. Some time ago I posted script examples and a full description of the process, but I can't remember the title of the thread.

                  The original problem concerned corrupted indexes in a set with a single child table linked multiple times with filtered links. After a number of child record deletions, the indexes would crash. Open and closing the form on save allowed the indexes to update correctly.

                  Jerry

                  Comment


                    #10
                    RE: another mystery

                    hi jerry:

                    thanks for the help! this may be a duplicate post, windows went wonkey when i hit the send button.

                    most definately this is the same problem we are seeing. if closing the form fixes it, you have solved my problem. thank you!!!
                    under normal data entry the post button would close the form at the end of the script. i had that line commented out so i could "test drive" a number of invoices at once. as you stated after about 8 to 15 entries i would get the message. how's that for ironic ... code that fails on the bench and os fine at the end user level.

                    thanks jerry.


                    top of the season once again !!!

                    ed

                    Comment


                      #11
                      RE: another mystery

                      Ed,
                      Have the problem consistently. While closing & opening cures it, try "ENTER", "LEFT ARROW", "ENTER". Doing this once or twice USUALLY gets by the problem, & saves time. Otherwise close & open.

                      John Gamble

                      Comment


                        #12
                        RE: another mystery

                        hi john:

                        thanks for your reply. closing the form should work great in this app, but for future reference i'll keep your idea at hand.

                        it's funny, when i started programming in a5, every time something didn't work i immediately suspected it to be a bug in a5. after many humbling helps from this board i had stopped questioning a5 and started getting to the point of fixing my code. do we ever learn to "doubt everything" when dealing with the unknown?

                        regards,

                        ed

                        Comment

                        Working...
                        X