I heard that it's a bad idea to use that, so I haven't. I don't remember who/what/where I heard not to use that - but it seems like I remember playing around with it and there was some issue if a user wanted to cancel an action - it was skipping the next value...I could be wrong about that. Now I know for sure AutoInc does not work with remote views - and based on what you're saying I'm guessing that this DOES work with local views. Anyway even if I ran across a VFP app that used this I would just change it in the VFP table and be done with it. Still end up a lot less hassle than all the other jazz I'd have to do. One thing I do not know is what the advantages of using AutoInc are other than saving a line or two of code and keeping track of keys yourself.

>AutoInc fields.
>
>>>Because you have to code the lowest common database. You get no benefit from anything added to VFP databases after VFP 6.0. Can you work around this? Maybe. Maybe not. Depends on you business needs. It's a great concept, in theory, but I've rarely heard of it working well.
>>
>>Ya that's true - lowest common database and with the ODBC driver that's VFP6....but I can't think of a business need where this would become an issue - surely there are some I haven't run across yet - can you give me an example?
>>I guess I'm the rarity because over the past 10 or so years I've got 18 VFP apps (almost 19) that are using this method and they all seem to work excellent...:)
>>
>>>A better solution really is to have a data access layer that can use the benefits of each database and have all the data access go through that layer. Yes, you have to maintain all that code, but it really ends up benefitting the customer because you can use the power of whatever database you connect to.
>>
>>I agree 100% with that - however if the customer has a VFP database - which has table size limits of 2gigs - then it's not really going to be necessary to use the full power of an Oracle or SQL database when switching to one of those. Depending upon the customer they might be happier saving the 100's or even 1000's of hours to write the data layer as opposed to saving .00001 seconds on a query.
>>
>>..oh almost forgot. Once of the reasons I like remote VFP views better than local VFP views is because the local views actually opens the table in the datasession - the remote views don't.
>>
>>>>But why would I want to do that when I can just maintain ONE set of views in ONE dbc?
>>>>
>>>>a) One DBC (holds nothing but remote views)
>>>>b) One set of views (change connection string in DBC to change backend - that's all you have to do, no recompile)
>>>>c) Zero code changes to application when switching backends
>>>>d) App is using same set of views - simpler to test and maintain.
>>>>e) Still able to use forms' data environment
>>>>
>>>>I just don't understand why you would want to go though all the hassle of maintaining two sets of views and loading up your app with USE blahblah ALIAS realblahblah when all that can be avoided. Plus if one set of views didn't match the other set of views & it creates a bug - now you got a hassle because you have to figure out if it's because the views are different or if it's the code.