>>>>>>>>Cindy,
>>>>>>>>
>>>>>>>> I guess, you're right. This is very important question, so keep it for DevCon, please.
>>>>>>>
>>>>>>>I've tested this with up to 21 items in the IN () statement without problem. However, in my test, the length of each item in the list matched the width of the field. Note that if the length of the field is wider than the items in the list and ANSI is set to ON the shorter items are padded with spaces. This will cause something like "CHI" in the list of items not to return a value for "CHICAGO" in the city field.
>>>>>>
>>>>>>
>>>>>> George,
>>>>>>
>>>>>> Try to test with 25 items. You will get an error message... I tested with the table, which has town (code) 4 character. Firstly I opened this table and wrote down couple of codes (guess, I could print it instead...), then I wrote the select statement in command window. I listed 13 items, but I got only 11 records. Anyway, I continued appending the list, and then I added 25th item, it gave me an error... I tested with VFP table.
>>>>>
>>>>>Nadya,
>>>>>
>>>>>You've just hit the limit is all. It isn't a bug. If you're willing to sacrifice compatibility with ANSI standard SQL, store the list items in an array, and use ASCAN() > 0 to achieve the same results.
>>>>
>>>> My question is: where in Help can I find, that IN is limited by 24 codes? I know, it's true for INLIST(), but I didn't find a mention of it for IN, if it's the same in this context. I didn't understand your suggestion about ASCAN(), could you please be more specific.
>>>
>>>It's a memory limitation. VFP lacked sufficient memory. That's what the error (1845). VFP ran out on memory when it tried to expand the statement. I can't test it, but it may vary depending on the amount of memory. INLIST() limited to 25 items? I just ran the same query, that generated the above error with IN (), using INLIST() with 25 items and it worked fine.
>>
>> From the HELP about INLIST() function:
>>
>> eExpression2 [, eExpression3 ...]
>>
>>Specifies the set of expressions to search. You must include at least one expression (eExpression2), and can include up to 24 expressions (eExpression2, eExpression3, and so on).
>
>It may be that one of the SPs raised this to 25. That's the current limit according to my tests.
>
>>I've never tried it with 25 items, because I believe the printed document... :)
>>
>>Anyway, I think, it should be somethere in Help that explains the limitation of IN() function... Currently, it isn't. So that's the point.
>
>The problem is how to accurately document something that may be machine and/or environment dependent? In this case, the generated error tells you what the problem is. Further, as far back as FP 2.0, when I think (I never used 1.0) the SQL statement was introduced, there have always been limitations with expansion. Further, there probably will always be some, and they may not be limited to simply the IN () function.
>
>During design time, when an error like this occurs, it is incumbent on the developer to investigate it, determine the cause (in this case the function), and then devise a different solution to overcome it. Asking for documentation that say, "there's a limit of < n > arguments" where it may or may not always be the case is worse than omitting a mention entirely.

Ok, I don't want to argue should it be or not in the documentation, I just want to say, what if you don't know about this limitation, you would be probably hit by it sometime. I agree, that limit could be empirically determine depending on configuration.

Anyway, I think this discussion shows that the problem exists. Now it's a programmer responsibility to deal with it :) Do you agree?

Thanks.