Well it seems simple enough just not use this data type...which is what I've done in the past. I mean I'd rather change one datatype one time than be dealing with extra miles of code and multiple DBC's and code that has to be debugged multiple times because all the datasources have changed.

Part of my thinking years ago when I came up with this approach was this:
I had a client who had a VFP app - but they had one customer that was nearing 2gig limit on a couple of tables - so they wanted to put that customer on SQL server. The other clients didn't want to have to pay for SQL Server & could not use SQL Express because all of the tables together were beyond the limit and/or too many connections.
So by doing it my way - they have the exact same source code and exact same views for the customers no matter if they use VFP tables, SQL Sever tables, or SQL Express tables. If a customer wants to 'upgrade' to the SQL Server backend then they collect a nice chunky 'upgrade' free, run a gizmo that copies all the tables to SQL server and changes the connection string...and poof! you're done. Another customer wanted to use mySQL so again exact same thing. Like I said this has worked out for me prefect thus far. One DBC, no specialized coding based on backend used, all control sources in app remain the same, able to use forms DE's...etc etc etc.

Yes it's not prefect because you have to design your databases just right and might miss out on a handful of new DB features - but considering the huge amount of time this saves and how significantly easier maintaining the app for multiple backends it is I think it's waaay worth it.

Another advantage of this is you can upgrade to SQL server backend in increments. For example - we had one table that was hitting two gig - all the others were fine. So be having two connection strings (one for VFP and one for SQL) I was able to have that one table in SQL and all the others still using VFP. Then it was just a matter of going though the app and upsizing the tables a few at a time till they were all done.

>AutoInc doesn't work on a view. It works on the actual table. Skipped values are inconsequential as they are only used by the system. But, if the user cancels, it's before the process of inserting a record, so it shouldn't matter anyway.
>
>>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.