George,

>See my post titled, "Why Auto-Increment May be a big deal."

I've seen it, but I think with this message I'll say all I have to say. So I'll keep this my last message for now.

>Personally, I think you're being negative and/or trying to find reasons to be so. I'm an optimist.

As a highly motivated developer I always try to find the details to find out what is best. In the case of autoincrementing keys I clearly see differences in the way we use a custom auto-generating routines now and how the native auto-incrementing key feature in Toledo. I tried to express the differences and warn people that the two are not fully compatible, so you'd better think twice to use it.

The autoincrement feature in other DBMS like SQL-server has been critisized by pure RDBMS guru's like Joe Pesco (and probably C.Date and E.F. Codd too) because at one end it violates the RM at the definition what a relation (table) should be. I do not neccesarely agree with RM purist, but at the practical level I only see one advantage over a self made autogeneration key routine: "performance". On the other end, I see potential dangers and limitations (e.g. working with buffered data and local views).

OTOH, I do see why there are people requesting this feature. Newbee's and less experienced VFP developer are faced with a problem how to generate new keys. They don't see an easy solution until they come up onto a forum like this and they're told how to write a autogeneration routine. I remember that at the beginning I also struggled with generating keys and it took at least a few years before I saw the light. I'm sure that if VFP (FP 2.x at that time) provided a native autoincrementing feature I would have used it. OTOH, I'm not convinced that is the best solution. IOW, the obvious choice might not be the best one. Too me it's like having the GOTO statement in BASIC languages: It might be neccesary to solve certain problems in particular cases (mostly due to limitations in the language), but has a highly risk of beeing abused by developers on a large scale.

For the argument of getting VFP closer to SQL server. I don't see the value of upsizing at database this way. The upsizing process is complex and difficult of you want to do it well. Like Erik M has said before "I don't believe in an easy upsize". On too many levels the VFP DMBS differs greatly from SQL server. Before you upsize you'll have to think how to solve incompatibility between SQL server and the xBase commands like SEEK, SET ORDER TO, SET FILTER, GO, SKIP, Etc.

Bottom line: I do understand why this feature was included into Toledo and I do understand the power of "Other DBMS have, so VFP should have", but on the other hand I do not see much value in it and potential problems.

>I know this, Ken Levy is a helluva lot smarter than I am. I would, if I were in his position, be trying to move VFP closer to SQL Server. This does that at the least. You seem to want the worst for VFP. I want the best.

We've the same goal, only different viewpoints of what is the best. If you look at the numerous Toledo wishlists I posted you'll see a number of database ERs that are a lot more stunning than this one.

IMO, For the future of VFP it is best to always have distictive features in VFP. The power of VFP could/should be that it is different from SQL server without losing compatibility. So at one end, I agree that more compatibility with SQL server would be nice, at the other end I say that to have more power than SQL server, please let us take advantage of the the independance of the xBase database. For example: make filtered indexes rushmore optimizable.

>I can tell you, without reseveration, what you won't see in Toledo. Again, this is simply my opinion. You won't see native windows controls. The benefit is clearly outweighed by the cost. You won't see a "native" compiler". Sorry, under Win32 "thar ain't no such animal."

I'm quite aware that those features won't make it, nor do I see any value in them. Native windows controls would require a total rewrite of the VFP GUI which time I'd better be see used for other things. Also I wonder if there are going to be some disadvantage are attached to this.

As for a native compiler, what advantages would this give us ? maybe a 5% more performance in overall cases ? It would have the disadvantage of having a much slower compiler, VFP looses the features connected to the runtime compiler in the runtime library (&, EVAL, COMPILE commands). This is not what I want to see.

Walter,