>Hi folks, I just stumbled across what I consider to be a *major* bug in the SQL SELECT parser. I have a table with a character primary key - cIssue_Pk, 5 bytes long. I want to increment this key under program control so I use the following statement to obtain the current "highest" key - SELE FROM Issue MAX(VAL(cIssue_Pk)) AS pk INTO CURSOR CurIssue - I get back a cursor conatining ALL the primary keys found, as numerics. If, however, I use this statement - SELE MAX(VAL(cIssue_Pk)) AS pk FROM Issue INTO CURSOR CurIssue - OR - SELE MAX(VAL(cIssue_Pk)) FROM Issue AS pk INTO CURSOR CurIssue - I get the "correct" single record cursor with the highest value... BTW, the second "correct" statement above is also illegal since the AS clause follows the "FROM Issue" and is not after the field statement as it should be. Not too cool.
>
>This gives me a ton of confidence as to the veracity of the result sets I get back from VFP when doing SQL SELECTs. This is a SIMPLE, one field, no joins or unions, SELECT and yet VFP 5.0a cannot give me accurate, repeatable results. Great product.
>
>If this has been documented previously, please excuse this post, otherwise just another screw-up by the boys at MS - where is 5.5 when you really need it?
>
>Oh, yeah, Lewis just called me over to his machine to see where VFP would allow him to key local variables into his method code, and when he saved it (using Ctrl+S), they disappeared right before our eyes!!! He had to exit the form and pull it back up before he was allowed to save his changes. This form was NOT in Read Only mode. Yeah, one rock solid product we got here...
>
>Bummed in DC,
>
>-RW-

Richard,

Just a suggestion. You'll get better performance with either

SELECT MAX(cIssue_Pk);
FROM Issue;
INTO CURSOR CurIssue

or

CALCULATE MAX(Issue.cIssue_Pk) TO lcCurIssue

than from the correct sample above.

Given the complexities of SQL syntax, it's not surprising that this got by the compiler. But that's why we test these things, isn't it?

George