Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 8 SP1
OS:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01173246
Message ID:
01173511
Views:
10
>Hi again, Naomi. Is it just my imagination, or haven't we talked
>here on UT before? :^) :^)
>

Yes, we did talk, I remember you.

>
>>Just wanted to point out, that this is an old application converted and it uses old style
>>of indexes INDEX ON somefield TO someindex.idx instead of index on somefield TAG Something.
>
>I learned VFP by reading the VFP 6.0 book by Hentzenwerke, so some
>of the syntax I use is the older style. Lately, though, I've been
>using VFP's built-in help facility, so things are looking brighter.
>Another thing I've found useful is to lurk here in the VFP groups,
>listen to you guys define problems, and then look up every command
>I have no clue about. After doing that, I see if I can find the
>solution, and then I continue to read the thread until a solution
>is provided, looking to see if I came up with the same solution
>(or something there about). Sometimes, I actually get it right :^).
>
>>You probably would not encounter a problem at all using structured indexes.
>>
>>Also I guess my record is out of range problem was mostly caused by bad indexes.
>
>I was leaning in that direction, too, especially when I read the
>chapter on row-column style indexing, knowing that if one little
>thing was out of place...WHAM! :^)
>
>> I did switch to array solution as a cleaner alternative and I also re-indexed my tables.
>
>Kewl.
>
>>I had this problem with local version of data and don't have a problem with the old code in production,
>>so I really think the problem is related with the bad indexes...
>
>Same here; however, I'm wondering how the indexes got thrashed to begin with?
>I'm pretty sure I remember reading in the VFP 6 book that, from time to time, indexes
>need to be rebuilt. It also mentioned that we should consider index corruption well
>before we consider table corruption.
>

Yes, it's a valid comment. It's a good idea to re-build indexes with some frequency...

I'm not sure how the indexes got corrupted here, but once I fixed them, they worked...

>>BTW, I found select sum(..) from sometable where somecondition into array laArr doesn't create an array
>>if the condition is not met in VFP8. Is the behavior different in VFP9?
>
>Hmmm. Don't know. Since I'm not too busy today, I'll see if I can write a test program and find out.
>Either that, or I'll sick one of my interns on the problem as an exercise :^). Hey, they might
>as well learn what real-world code hackin' is all about :^).
>
>Either way, it should be easy to figure out. Just run the select with bogus criteria, never
>matching a record, and then see if the array exists. If it is created in 9, you'd think that
>all the array elements would be NULL. (Shrug.)
>

I don't have VFP9 available here to try, but if I recall correctly the behavior was changed. If it would be NULL, my EVL code would not work correctly and I have to check for empty and IsNull then...


>>so I just put cRate = evl(laArr[1],0) (don't ask me about cRate for the numerical value, I didn't create such names)
>
>Kewl. If it returns a value, calculate, and if it returns zero, then on to the next record.
>
>Anywho, good luck on getting it working.
>
>Regards,
>
>Randall

Thanks and thanks again for helping me to go in the right direction...
If it's not broken, fix it until it is.


My Blog
Previous
Next
Reply
Map
View