Hi Tore,

Well, there's redundancy and then there's clarity.

I think that including them both makes it very clear as to what one wants.
In addition, should the day come that READWRITE no longer creates a 'real' cursor, then having them both ensures that there is continuity of processing (i.e. no surprises).

cheers


>Hi Jim,
>
>AFAIK both NOFILTER and READWRITE create separate "real" cursors, so if you include READWRITE, the NOFILTER clause is in fact redundant.
>
>>Jim,
>>
>>While I suspect that including READWRITE will have the same effect as "NOFILTER", I believe that it is really "NOFILTER" that 'addresses' the problem of avioding a "filtered result set".
>>There would be no harm in including both for clarity.
>>
>>cheers
>>
>>
>>>Thomas --
>>>
>>>Wow! You've done a quite a lot with this -- a lot more than me. I simply addresses this forum as soon as I could tell what was going on.
>>>
>>>Thus far, I have merely changed my code by doing two things: including "READWRITE" (so that it is on disk) and closing it before re-using it.
>>>
>>>I have not had any recurrences of the problem, but I can't really say that this is a solution, either, as the problem may just have gone into remission for awhile. It's not predictable or entirely duplicatable, as you know, so it may still be lurking. For now, at least, this seems to have been a solution.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Hi James,
>>>>
>>>>this one sounds hauntingly familiar: I am right now battling something VERY similar <g>.
>>>>
>>>>My take on the behaviour is that alias() is never set correctly in the first place instead of "disappearing".
>>>>
>>>>Put something similar like (not tested, just along my "fix")
>>>>

>>>>if !"MYCOMPONENTS" == UPPER(ALLTRIM(ALIAS(SELECT())))
>>>>   assert .f. Mess "Error Situation Alias() not set correctly, check Set and Watch"
>>>>   local lcErrorAlias, lnErrorSelect, lcErrorDbf
>>>>   lnErrorSelect = select()
>>>>   lcErrorAlias = alias()
>>>>   lcErrorDbf = dbf()
>>>>   = StrToFile(Transform(m.lnErrorSelect) + "!" + m.lcErrorAlias + "$" + m.lcErrorDbf, ;
>>>>   "MyAliasProt.Txt", .t.)
>>>>   if used(Select("MyComponents")
>>>>      Select("MyComponents")
>>>>      use
>>>>   else
>>>>      select 0
>>>>   endif
>>>>   Do while .t.
>>>>      use (lcErrorDbf) again alias ("MyComponents")
>>>>      if "MYCOMPONENTS" == UPPER(ALLTRIM(ALIAS(SELECT())))
>>>>        use in m.lnErrorSelect
>>>>        exit
>>>>      else
>>>>        lnErrorSelect = select()
>>>>        lcErrorAlias = alias()
>>>>        lcErrorDbf = dbf()
>>>>        = StrToFile(Transform(m.lnErrorSelect) + "!" + m.lcErrorAlias + "$" + m.lcErrorDbf, ;
>>>>        "MyAliasProt.Txt, .t.)
>>>>      endif
>>>>   endif
>>>>   = alias()
>>>>endif
>>>>

>>>>after your select statement, taking care that the cursor is never closed before attaining
>>>>the correct alias() and only one workarea is linked to the cursor afterwards.
>>>>
>>>>I have a situation that calls of
>>>>

>>>>  use (m.pr_path) alias (m.gp_alias) again
>>>>  pr_isused = .f.
>>>>  select (m.gp_alias)
>>>>

>>>>failed on the select. Any workarea with used(m.gp_alias) is closed before.
>>>>
>>>>Please check if the new assert fires (behaviour I found under vfp6Sp5):
>>>>- alias() in the watch window "fluctuates" (you'll recognize it if you see it <bg>)
>>>>- in the set window the alias shown for the cursor is something like "default data session(1)"
>>>>- in the variable lcErrorAlias sometimes part of lcErrorDBF (including "/"!!!) is reflected
>>>>
>>>>which is happening at my place. I can send you a few screen shots of mine, and I will set the assert in my code to see if the unusual behaviour can be seen in vfp8 debugger/set window as well (the app is now running for the first time after being ported to vfp8 - they wouldn't wait for vfp9...).
>>>>
>>>>I happens once in a few million calls in a datatransformation app running for a few hours.
>>>>If I have a data set where the error is likely to happen, I can recreate it with this data set across different machines. The error is never exactly on the same input line from the file read, but in the same area (for instance fluctuating between 65.9% and 66.3%) of the items processed.
>>>>
>>>>I cannot stop "before" an error, save all my data and start again to analyze the error which should come up in the next few %, because then the error doesn't manifest: running for a few hours before seems to be part of it - which makes it a PITA to try to get a handle on it. I always have to start at the beginning.
>>>>
>>>>Verified: the error can be found in vfp6SP5, vfp8Sp1, vfp9OpenBeta.
>>>>Verified: The error can be found in W2K Prof SP4.
>>>>Verified: The error can be found when running the app in the IDE of vfp.
>>>>Verified: The error can be found on Intel PIV and Athlon CPU's
>>>>Verified: The error can be found on disks with NTFS
>>>>Verified: The error is not linked to private Datasessions, since this is an old FPW-port running always in Default Data Session
>>>>Not disproved yet:
>>>>

>>>>according to more than a dozen protocols:
>>>>  The error is fixed on the first run of the correcton loop, if handled programmatically
>>>>The error hasn't shown up under NT4Sp6
>>>>  (it started a few months after moving to W2K,
>>>>   only sporadic tests with NT4 with both vfp6 and vfp8 with GDIplus)
>>>>The error hasn't shown up when running the runtimes (only 3 test runs yet)
>>>>The error seems to come "easier" on machines with fuller/less fragmented disks
>>>>   (might be relevant, since in my case the table has been closed after many changes before)
>>>>

>>>>
>>>>Encapsulating all "Use" into a function with explicit check on the alias() asked for makes it possible to work, but it leaves a very disturbed feeling here - if you cannot trust a simple use in alias, what else might fail?
>>>>
>>>>If you want to exchange more, you are welcome to contact me directly via email. My "real" code has a few more twists perhaps easier understood if seen in the bigger picture.
>>>>
>>>>regards
>>>>
>>>>thomas
>>>>
>>>>
>>>>>Any guesses on how an alias can disappear?
>>>>>
>>>>>I have the following:
>>>>>

>>>>>      SELECT * FROM components INTO CURSOR MyComponents ;
>>>>>         WHERE KitID==lcPartNo
>>>>>      llIskit = 0<RECCOUNT("MyComponents")
>>>>>

>>>>>This is in a loop that is executed a few thousand times. On rare occasions, the second line fails with "alias not found" ... and when this occurs, ALIAS() is empty! That's right, I get a cursor with NO alias.
>>>>>
>>>>>Any guesses on how to get around this? (No, it's not as easy as doing RECCOUNT() -later on, having done various and sundry other things with other SELECT statements, I need to get back to this alias --)
>>>>>
>>>>>Thanks