>I am sure they work fine... as a matter of fact, you will see that I sent Ken a solution to his problem... I like identity fields... But there are times when other methods are better... remember, use the correct tool for the job.

For PK's, they are the right tool. For other incrementing values, I agree that a key table with an incrementing value is fine. Just don't use a DBF. Rather, keep it in SQL Server if that is what you are using...

>Well, we are in the Fox box when we talk about whether to use Remote Views or SPT aren't we? Obviously if we were in VB it would be a different question.
>

With respect to to the view designer yes. With respect to SPT, no.. You can use SPT in VB. Prior to ADO, you would need to work with RDO and DAO. But, you could still use SPT.

The View Designer is an incomplete wrapper around SPT. It sucks...


>You have been preaching DON'T USE REMOTE VIEWS...THEY ARE THE DEVIL... and, every reason I have heard (From you and Rod) to not use them has been generally a problem or issue with the VIEW DESIGNER!
>

>So, are you preaching don't use Remote Views because the View Designer has some short commings? Shouldn't you be saying DONT USE THE VIEW DESIGNER??? You wouldn't be the first to say that.
>

I really don't have a problem with SPT.... SPT is not a VIEW. The only knock against them both is that the end result is a VFP cursor. You cannot pass VFP cursors to components....

>And, not to knock SPT, but Views for CRUD forms and SPT for validation... is my preference. Of course, I work on a project where we are supporting LOCAL and REMOTE data... if I was purely SQL Server, I might use a different technique.
>

Using a view to display data, and something else to validate/update, if there is a place for views, that is it...

>Anyway... how did we get on this thread... Ken has his solution.

Just taking it a step further...

Good discussion Bob... :)