>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

Thanks for the reply, George. Can't use CALCULATE, this is a character field (cIssue_Pk, "c" means character), *have* to use MAX(VAL(etc...

As for the "complexity" of the SQL syntax - no joins, unions, etc. this is a single field select...And, guess what, I just ran the exact same statements using VFP 3.0b - IT TRAPS THE BAD ONES AND RETURNS AN ERROR! This is CLEARLY a bug! It is NOT my video driver, or my system's memory, or my motherboard, or , as others would have you believe. Where's that copy of PowerBuilder...

I was able to catch this bug because the result set was so obviously wrong, but what about more complex queries that return multiple records, maybe hundreds or thousands? Would you bet your life on the accuracy of this product's SQL implementation? I would not.

Late breaking update: I tried your suggestion and SELECTed the MAX(cIssue_Pk) and it returned the MAX alright, of a DELETED record (00010)!! Whereas the MAX(VAL(cIssue_Pk)) incorrectly returns 9.00 It completely ignored the status of SET DELETED, which is what it's supposed to do, when using just MAX(), but respected it when using MAX(VAL()). So, if you combine functions, you ain't got a clue if this stuff is right or not. BOGUS, TOTALLY BOGUS!! Where's that copy of PowerBuilder...

-RW-

-RW-