>Richard,
>
>As I look at these I'm surprised any of them give you correct results without a GROUP BY being specified. BTW these all leave you open to getting duplicate PK's as the table is not locked while you do this and another sattion can do it before you have completed adding you record. A much better approach is to keep a separate table with the next Id whihc you can select, lock, get your id, increment the Id, and UNLOCK. This preserves multiuser validity on the PK's obtained.

Yes, I have used separate tables in the past, but this is a "quick and dirty" single user system. There will be no file contention issues.
BTW, GROUP BY has no effect on the result set in this instance. Since each value is unique (primary key, remember) GROUP BY doesn't help - I tried it already...

>
>SELE FROM Issue MAX(VAL(cIssue_Pk)) AS pk INTO CURSOR CurIssue
>SELE MAX(VAL(cIssue_Pk)) AS pk FROM Issue INTO CURSOR CurIssue
>SELE MAX(VAL(cIssue_Pk)) FROM Issue AS pk INTO CURSOR CurIssue


1) SELE FROM Issue MAX(VAL(cIssue_Pk)) AS pk INTO CURSOR CurIssue - CORRECT SYNTAX, INCORRECT RESULT SET

2) SELE MAX(VAL(cIssue_Pk)) FROM Issue AS pk INTO CURSOR CurIssue - INCORRECT SYNTAX, CORRECT RESULT SET

3) SELE MAX(VAL(cIssue_Pk)) AS pk FROM Issue INTO CURSOR CurIssue - CORRECT SYNTAX, CORRECT RESULT SET

MAX should cause VFP to return only 1 record. No exceptions. BTW, ALL of these statments get by the parser and generate no errors. I am going to try them on 3.0b tonight and see what I get.

>The parenthetical comments only make your messages have more to read and take longer to respond to. They also irritate.
Sorry. Although, since they were not directed at you (only MS), it seems you are easily irritated.

>>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? <<

>Again why do you have throw daggers at the folks at Microsoft.
I throw daggers at MS because Borland didn't write and sell this product. MS did. They made the profit, they get the flames. Also, why do they always take away something and give something back with each new release? Ex.: 2.6 had FILER and BEAUTIFY, 3.0 had FILER, no BEAUTIFY. 5.0 has BEAUTIFY and no FILER. What gives? And, yes, I know about FILER.DLL - TOTALLY LAME! I have to keep 3.0 running and Alt+Tab to it when I need FILER. Bogus.

>BTW, they won't cause duplicate keys in your system .
Only because they generate a "Primary key has been violated" error. The last time we got an interim release was back when this stuff was still under Fox Software's control. Since then, nothing but X.0 releases. Hell, they even tried to bullshit me about 3.0b, saying it didn't fix *any* bugs and was for international compatibility only. Except, I had access to an internal MS document showing that 3.0b fixed over 70 known bugs!! They need to stand up like real men, cop to their mistakes, and fix 'em!! We'd all respect them ever so much more.

>>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...<<

>Was the title bar of the edit window telling you it was read only?
No. In fact, he had previously edited and saved this very same method several times before this behavior occurred. Just plain weird.

Back to work,

-RW-