That was a strange post. Not your comments, but the way it appeared. No word wrapping - so it was really wide and I had to scroll left and right to read it. Never seen that problem on the UT before.
Anyway, I don't know who expressed the surprise about that tip you mention, but since the FOR clause is reevaluated each time through the loop, then the UPPER function would get called each time and would result in slower execution. As for this case of referencing the TABLENAME.FIELDNAME as opposed to a memory variable that has the value of the field in it, I'd be curious about that. Maybe I'll write a little test. For big SCANS, I'm going to be looking for every little trick to coax more speed out of VFP, but for a little table like this, it's kind of a "6 of one or half dozen of the other" situation.
>That's because we see this very differently. SCAN FOR invokes Rushmore Optimization - we can only guess at its inner workings. But if there are 10 records, there is a possibility that VFP is trying to access ModuleUsers.user_or_group at least 10 times.
>
>Assigning a field to a variable and thereafter accessing that variable is a much simpler operation.
>
>There was an FPA tip some time ago that expressed surprise that this...
>
>
LOCATE FOR upper(field) = upper(m.variable)<pre>
>
>is slower than ...
>
><pre>variable = upper(m.variable)
>LOCATE FOR upper(field) = m.variable
>
>
>
>>Well, under normal circumstances I wouldn't consider that an improvement, however in this case it may add value. The problem is that it can't get the memory variable populated if it can't get to the table, however I'll give it a try 'cause it certainly won't make matters worse.
>>
>>
>>>There is less chance that the scan will have trouble with a simple memory variable, especially if a network problem is making the cursor vanish or something. Just because code has worked doesn't mean there is no better way to write it.
>>>
>>>>As I was trying to point out, the form that calls this code resides in a private data session, but the code that executes and that is throwing the error resides in the default data session. From there it runs and builds an array that is passed back to the calling method. So it's not like I'm trying to refer to the cursor that resides in the default data session from the private data session. The issue of changing data sessions is moot and not what is causing the problem. Your code change suggestion is appreciated, but any speed increase is not perceivable since this table is going to be quite small. Thanks, though.
>>>>
>>>>
>>>>>Hi Russell
>>>>>
>>>>>I'd make a little change to the code.
>>>>>
>>>>>
LOCAL lcUserOrGroup
>>>>>lcUserOrGroup = ModuleUsers.user_or_group
>>>>>scan for group_name = m.lcUserOrGroup
>>>>>
>>>>>I believe it would be faster for VFP to access a memory variable than a field name. I believe it would be safer to avoid potential effects of changing the record pointer in ModuleUsers. I'd expect changing data sessions to result in an Alias not found error with your code.
>>>>>
>>>>>>Unfortunately, this is not your standard "Variable is not found" error. Here's what's going on:
>>>>>>
>>>>>>I have a combo box that will list the users who have security rights to a given form. This is so that when a user adds a record, but the user adding the record is not the logged in user, he or she can select their own name from the list of authorized form users to indicate who actually added the record (instead of it defaulting to the logged in user). This has been in place for a good while and has been working just fine. But recently they've been getting intermittent errors. The line that throws the error is:
>>>>>>
>>>>>>scan for group_name = ModuleUsers.user_or_group
>>>>>>
>>>>>>and the error is:
>>>>>>
>>>>>>Variable 'USER_OR_GROUP' is not found.
>>>>>>
>>>>>>ModuleUsers is a cursor created with this code (which, of course, runs before the code above):
>>>>>>
>>>>>>select distinct rights.user_or_group;
>>>>>> from rights;
>>>>>> where alltrim(rights.r_module) == MyModule;
>>>>>> into cursor ModuleUsers
>>>>>>
>>>>>>There is no conditional code around that SQL Select statement, so it executes every time (the combobox calls the UsersWithRightsToModule procedure, which has all the above code in it). Of course, if the SQL statement returns no records, the cursor is still created. So referring to it as I do in the SCAN statement should not cause an error.
>>>>>>
>>>>>>At present, I attribute this to some sort of network or hardware error. Over the past two days, they have been having very bad network problems causing people to not be able to log in and even locking up their workstations. Additionally, in the past, I've seen an error that was similar. I have an internal messaging feature built into my apps. It uses a table called MESSAGES. Every 60 seconds the table is checked for incoming messages for the logged in user. This code has been in and working from day one. But back in February it started throwing an error 13 (Alias 'MESSAGES' is not found). MESSAGES is opened at system start up and never closed. Additionally, if the table is not open for some reason, the ChkForMsgs procedure will open it. So to get that error was quite bizarre. I attributed it to some sort of network disconnect. VFP knew the file was open, but then couldn't actually access it.
>>>>>>
>>>>>>At present, I can see no problem in the code and this is code that has always worked fine and that I haven't changed in quite a while. So I attribute it to hardware and/or network issues. I've seen hardware issues at another client cause the most bizarre errors, but only on one machine. Replacing the machine solved the errors. So I certainly know that it can happen. However, I'm always willing to take another look at my code. Does anyone see any issues or know of anything that might cause errors such as these?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Russell Campbell
