Hi Pete,

>May I ask a kind of novice question about this to autocrement or not debate?
>
>Many of you have developed -- or obtained -- classes to handle keys; they have been tested, tested, and tested, and so they are as rock-solid and free from bugs as one can ever expect. So what will be the advantage of having a new VFP autocrementing feature? Perhaps, as some of you have suggested, new VFPers will like them. So why not include a class (not a native feature) in the VFP software? The advantage of classes, as I am learning, is they can be subclassed and customized to meet our individual needs. FWIW, I've tried the Access autocrementing feature and am using the class way in VFP. As I novice, I much, much prefer the current VFP way.
>
>...just wondering,
>Pete

Good question...

I'd think, as some have stated, that since they have their own developed methods for generating PKs that they will stick with them no matter what. In my opinion that'c totally reasonable. On the other hand, someone may not have had the chance to developa PK-generating routine so they'll just use the one supplied by Microsoft. In my particular case I generate my own, both on the local desktop and on our (transaction) server. I have a dual-key system that allows me to make sure that I don't get duplicate PKs. ALso, I use GUIDs, which some see as a lot of extra baggage but in my case was the quickest way for me to get where I needed.

As far as the method of distributing a PK-generating class I suppose you could send out a class. However, what with the new DBC stuff I'd think it just made more sense to attach the PK routine to the data more directly.



>
>
>>Hello Walter!
>>
>>How have you been??
>>
>>>Hi doug,
>>>
>>>>It has been mentioned that autoincrement has always been one of the top if not THE top requested item for the developers. Without regard to your other good suggestions it seems that it's been a major deal from the pov of most other developers.
>>>
>>>>Perhaps you don't have the need but just taking your needs may not be enough of a statistical sample to get the whole picture..
>>>
>>>I agree with daniel, it's not a thing a would vote for. As we will discover, the autoincrementing feature has some disadvantages over having a stored procedure generating the key for you. This will become painfully obvious when working with local views. The autoincrementing feature might cause you more headaches than it provides solution. I for sure won't be using the autoincrementing feature as longs as I am not able to generate a new key for any other purpose than just for a PK in a table.
>>>
>>>Walter,
>>
>>Well, I agree with you on one issue and that would be where a system needs to avoid duplicate keys being generated locallay and then combined together somewhere without taking precautions against duplicate keys. We do one of two things; Generate GUIDs locally or have the central server generate and control the keys. So far both have worked well for us.
>>
>>However... I recall that Ken stated that this feature has been the most requested new feature. I think that is why the VFP development team has addresses this issue. Yes, folks have created their own but for new folks I think it will be helpful. Of course, this sdoesn't deal with the issue of having a solid design. <s>