Alpha Video Training
Page 2 of 2 FirstFirst 12
Results 31 to 47 of 47

Thread: while .not. tbl.fetch_eof() not working

  1. #31
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: while .not. tbl.fetch_eof() not working

    Quote 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.

  2. #32
    Member
    Real Name
    Geoff Meredith
    Join Date
    Aug 2006
    Posts
    637

    Default 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()

  3. #33
    Member
    Real Name
    Geoff Meredith
    Join Date
    Aug 2006
    Posts
    637

    Default Re: while .not. tbl.fetch_eof() not working

    Cal - Thanks for the info.

  4. #34
    Member
    Real Name
    Tony Reynolds
    Join Date
    Sep 2006
    Posts
    394

    Default Re: while .not. tbl.fetch_eof() not working

    Will do.
    Thanks Geoff

    Tony

  5. #35
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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.

  6. #36
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: while .not. tbl.fetch_eof() not working

    Quote 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.

  7. #37
    Member
    Real Name
    Tony Reynolds
    Join Date
    Sep 2006
    Posts
    394

    Default 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

  8. #38
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: while .not. tbl.fetch_eof() not working

    No.

  9. #39
    Member
    Real Name
    Geoff Meredith
    Join Date
    Aug 2006
    Posts
    637

    Default Re: while .not. tbl.fetch_eof() not working

    G - Why not?

  10. #40
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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).

    Attachment 17969

  11. #41
    Member
    Real Name
    Geoff Meredith
    Join Date
    Aug 2006
    Posts
    637

    Default 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.

  12. #42
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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.

  13. #43
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: while .not. tbl.fetch_eof() not working

    Quote 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.

  14. #44
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: while .not. tbl.fetch_eof() not working

    Quote 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.

  15. #45
    Member
    Real Name
    Tony Reynolds
    Join Date
    Sep 2006
    Posts
    394

    Default 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

  16. #46
    VAR csda1's Avatar
    Real Name
    Ira J Perlow
    Join Date
    Apr 2000
    Location
    Boston, Massachusetts, USA
    Posts
    3,530

    Default Re: while .not. tbl.fetch_eof() not working

    Hi Cal,

    Quote Originally Posted by CALocklin View Post
    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.
    What you said is true for both append and update operations. If the index have to be updated (always for an append operation), and if an update field is used in any index for an update operation). However, if another thread has the table open (e.g. a form is open) or another user is using the table, then the indexes are updated on the fly after processing each record.

    To guarantee that Alpha uses the latter, I always open a form based on the parent table of the operation, as in the code

    frm=form.load("tablename")
    update.run_silent("updateoperationname")
    frm.close()

    If you do it by the above code method, it will run much faster if your Update filter invokes LQO (if using a subset of the table). Tests on a 35000 record file had an update take about 11 seconds in the above method, versus 19 seconds for the index rebuilds happening at the end (index expressions are very complex for this table) when the table is available exclusively.

    As you and I recently conversed about, measuring code speed for short time events is difficult, and the profiler functions of A5 gave wildly inaccurate values to the execution speed differences in the case you and I discussed. The only way to get an accurate time result is to run short time code pieces many times over, and make sure the loop overhead is not significant. The second part can be difficult to do.

    The accurate speed timing button of my CSDA Code Utility for Alpha Five does just that.

    So to get to Tony's question, is the overhead of an update faster than parsing through the records?

    For large numbers of records where either the index rebuilds don't take long, or using the method shown above to update indexes on the fly, normally the answer is yes. For under 10 records, it is probably faster with code, with 10 to 100 records probably being the cross over point. It's even possible to use both methods, depending upon # of records to process, if the value changes dynamically.
    Regards,

    Ira J. Perlow
    Computer Systems Design


    CSDA A5 Products
    New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
    CSDA Barcode Functions

    CSDA Code Utility
    CSDA Screen Capture



  17. #47
    Member
    Real Name
    Geoff Meredith
    Join Date
    Aug 2006
    Posts
    637

    Default Re: while .not. tbl.fetch_eof() not working

    Ira - Thanks for confirming my initial thoughts on the two methods.

Similar Threads

  1. tbl.zap() not working for me
    By Mike Wilson in forum Alpha Five Version 7
    Replies: 12
    Last Post: 09-23-2006, 11:15 AM
  2. '<tbl>.index_primary_put' not working
    By Michael Nesseler in forum Alpha Five Version 5
    Replies: 8
    Last Post: 04-12-2005, 11:40 AM
  3. <tbl>.fetch_next() not working
    By Scott Emerick in forum Alpha Five Version 5
    Replies: 6
    Last Post: 01-12-2004, 12:41 PM
  4. <tbl>.fetch_eof() problem
    By David Farr in forum Alpha Five Version 5
    Replies: 4
    Last Post: 10-14-2003, 04:38 AM
  5. <tbl>.enter_begin() not working??
    By Mario Prieto in forum Alpha Five Version 5
    Replies: 5
    Last Post: 04-09-2003, 06:37 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •