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

while .not. tbl.fetch_eof() not working

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

    #31
    Re: while .not. tbl.fetch_eof() not working

    Originally posted by gmeredith17 View Post
    Cal - What are the implications? I have started to use xbasic to accomplish some tasks and have used table.open() in a number of scripts where the form is not bound to that particular table. I am very interested in what the pitfalls might be in using this method. It might save me some future headaches and head scratching.

    Regards

    Geoff
    Only those two things I pointed out in the next two sentences - speed and resynching the current form.

    Using table.open() is really the only choice in the situation you describe where you want "to accomplish some tasks ... where the form is not bound to that particular table". And, just in case someone reading this is not aware, when the form is bound to a set, "bound to" includes ALL tables in that set - not just the parent table and not just those tables that actually have fields displayed on the form.

    Comment


      #32
      Re: while .not. tbl.fetch_eof() not working

      Tony,

      Try looking up the following in the help file. i I haven't used them but it may help.

      CURRENT_FILTER_EXPN()
      <QUERY>.FILTER_GET()

      Comment


        #33
        Re: while .not. tbl.fetch_eof() not working

        Cal - Thanks for the info.

        Comment


          #34
          Re: while .not. tbl.fetch_eof() not working

          Will do.
          Thanks Geoff

          Tony

          Comment


            #35
            Re: while .not. tbl.fetch_eof() not working

            Tony:
            I am having a busy day today so I will be brief:
            I didn't look over your design throughly nor do I know all your objectives but if the sole purpose of the alias is to display data that cannot be edited, then clearly you do not need the alias. Just put a browse of the child and restrict data entery/change.

            Your other questions about how to carry the current filter to table open(): there is just about a dozen diffrent ways to do that, BUT.. what gives you the idea that you need to do that in the first place?
            You don't.
            When you use table.open(), it opens the table with the most recently used filter... so here you go, you don't even need to worry about this issue.

            Comment


              #36
              Re: while .not. tbl.fetch_eof() not working

              Originally posted by G Gabriel View Post
              Although I am not a fan of aliases, I don't see that it contibuted anythng to the problem here.

              I hope the main point I was trying to make, and which I made a little rain dance around since it seems counter-intutive, is not lost. The point is: eventhough from everything you read and came to believe that you are better off, since the table is already open, you are better off to use table.current() and/or table.get(), I, at the risk of sounding off as a contrarian, believe for pragmatic reasons as shown in this example that you are better off with table.open() anytime all the time. Table.open() takes a direct hit at the table, very clean, reliable and fast, couterintutive as this might sound.

              Maybe one day I will come to regret having made such a bold statment, but that day hasn't come yet.
              I would agree with this except for one situation - and it has been a common one for me and for others. If you use table.open() to change values and especially to add new records to a child table of the current set, it can be VERY difficult to refresh/resynch the form to show those new changes/records. However, using table.get() or table.current() makes it very easy to "resynch" because you don't need to resynch at all - just refresh - and IT WORKS! Newer versions of A5 might be easier to resynch but I don't think so.

              By the way, I used table.open() almost exclusively for many years. In too many cases the result was that I then beat my head against the wall trying to make the result come out the way I wanted it to. In some cases I went so far as to save the record number/id, close the form, re-open it, set the appropriate index, and find the correct record. Once I discovered the benefit of using table.get() IN THE RIGHT SITUATION my life became much less frustrating.

              For those who aren't sure of the difference between table.get() and table.current()....

              The result is the same with either one - they get a pointer to a table that is already open.

              (On the other hand, table.open() opens a table in a new session which has no direct relationship to any other copy of that table that may already be open. Think of that as somewhat like another user using the same table.)

              The only difference between .get() and .current() is in how they identify which table to get a pointer to. Table.get() uses the name of the table to find it while table.current() uses the number of the table. As I've mentioned somewhere else on this board, I prefer "get" because (1) the number of the table is not intuitive - you have to look at the set structure and count down from the top and (2) the number of the table might change if you restructure the set. On the other hand (there's always a "but" in programming), if there are any alias names involved then even using "get" will be a bit more complicated.

              Comment


                #37
                Re: while .not. tbl.fetch_eof() not working

                Would this be a better way to accomplish the same goal:

                Code:
                dim tbl as p
                tbl=table.get("workouts")
                update.fields = 1
                update.field1 = "assign_workout"
                update.expr1 = ".t."
                tbl.update()
                Rather than:

                Code:
                dim tbl as p
                tbl = table.current(1)
                tbl.fetch_first()
                while .not. tbl.fetch_eof()
                	 tbl.change_begin()
                	 tbl.ASSIGN_WORKOUT=.t.
                	 tbl.change_end(.t.) 
                	 tbl.fetch_next(1)
                end while

                Comment


                  #38
                  Re: while .not. tbl.fetch_eof() not working

                  No.

                  Comment


                    #39
                    Re: while .not. tbl.fetch_eof() not working

                    G - Why not?

                    Comment


                      #40
                      Re: while .not. tbl.fetch_eof() not working

                      Because "Numbers are a stubborn thing".
                      (I don't quite remember, but I think it was Ronald Reagan who said this).

                      Comment


                        #41
                        Re: while .not. tbl.fetch_eof() not working

                        G- I haven't ever done any speed tests but I wonder if the update process has a larger initial overhead which makes it slower with small amounts of data but with large amounts might be quicker. It uses the descriptive term 'operation' in the help file which made me think it might be more suited to changing large amounts of data.

                        Just a thought, no actual evidence to back it up.

                        Comment


                          #42
                          Re: while .not. tbl.fetch_eof() not working

                          You make a good point, hence you should always test and see what works best. What works best in certain condtions, doesn't necessarily work in other conditions.

                          You used descirptive words as small and large amounts of data. What's small enough or large enough that makes one approach better than the other? Only way to find out, is test & retest.

                          Comment


                            #43
                            Re: while .not. tbl.fetch_eof() not working

                            Originally posted by reynolditpi View Post
                            Would this be a better way to accomplish the same goal:
                            ....

                            Rather than:
                            ....
                            Here's a more generic answer. I frequently ask myself the same thing, "Is this a better way?" The answers are....

                            1. If what you have is working reliably and fast enough, leave it as-is. (This is an important step that some people, including me, often miss. Being an engineer by training, I tend to go for perfection.)

                            2. If what you have is not working reliably, find a way that works. This usually involves building your own routines to test the results. The outcome of those results may vary from application to application because there is usually something just a bit different in each app/situation. Besides, you'll probably also learn something you didn't expect to learn during the process.

                            3. If what you have is working reliably but not fast enough, try to find a faster way. The only good way to do that is find some alternatives and test them on your own data because each situation usually involves something a little different than the previous one and that little difference can sometimes make a huge difference in complexity/speed.

                            A couple key factors in determining what fast enough means....

                            The first part of fast enough is, "Does it take so long that a user might get tired of the wait or think something is wrong?" If that's the case, something definitely needs to be done. If you can't find a faster way, at least add a progress bar. If it's a really, really long routine you might even want to give them a warning and a chance to cancel.

                            Sometimes there is just no way to make it faster so progress bars and/or warnings are the only choice - but don't forget them! I know people who've skipped these because "I can just train the user" but then a new/temporary person comes in, doesn't know what to expect, and messes things up by stopping the process mid-stream. Take a few seconds and add that progress bar and/or warning message - this will save your customer from having unnecessary trouble and expense and save you from having to take time out from another project to go fix the problem that could have been so easily avoided. (I think I've said this before but my dad taught me long ago that true selfishness comes from thinking long term - saving yourself 1 minute now so that you can spend an extra 2 hours later just isn't very selfish in the long run.)

                            Another consideration for fast enough would be, "Is it worth the cost of trying to find and test a better way?" If you are doing this for a customer, that customer probably isn't willing to pay you $200 to save 6 seconds each time a particular daily/weekly operation runs. On the other hand, if that operation runs every time a new order is saved and they get 100 orders a day, it's probably worth the cost. Besides the huge annoyance factor, at 10 minutes a day times 5 days a week times 50 weeks a year that's about 42 hours lost. The return on that would be less than 1 year for anyone earning minimum wage or better.

                            Finally, remember that finding the fastest way is usually not a 5 minute task. Even if you know what the alternatives are, setting them up and testing them will probably take at least 1/2 hour. Sometimes it could take many hours. Before getting too far into it, ask yourself if it's worth it or if another alternative would be more cost effective - in the long run.

                            Comment


                              #44
                              Re: while .not. tbl.fetch_eof() not working

                              Originally posted by gmeredith17 View Post
                              G- I haven't ever done any speed tests but I wonder if the update process has a larger initial overhead which makes it slower with small amounts of data but with large amounts might be quicker. It uses the descriptive term 'operation' in the help file which made me think it might be more suited to changing large amounts of data.

                              Just a thought, no actual evidence to back it up.
                              Actually, as best I recall, it's not the initial overhead; it's the final overhead. I believe an update operation changes all the records without updating the indexes as each record is completed. It rebuilds the indexes after the changes have all been completed. If there are many records to be changed, this is the fastest way. However, if there are only a couple records that need to be changed, the overhead of rebuilding all those indexes isn't worthwhile.

                              Comment


                                #45
                                Re: while .not. tbl.fetch_eof() not working

                                This makes perfect sense. If this type of information could be included in the help files:)
                                Thanks
                                T

                                Comment

                                Working...
                                X