>>Walter,
>>
>>It's a different design paradigm for a couple of reasons. Basically, in most instances, when you deal with SQL Server you're dealing with a sub-set of the table. Unless you're using a parameterized view of a VFP table, you're dealing with the entire table, and its indexes. As a result, assuming you wish to validate the contents of one table against another, and/or for business reasons, have to pull some information in from another. Typically, working with VFP, you'd simply have an index based on the search criteria and use that. With SQL Server, you may have a variety of choices: Parameterized view, index the entire cursor after retrieving it, use LOCATE, or something else?
>
>
>George, though you are perfectly right on the above, IMO you begin at the wrong end ;)
>As how you present it, it will be hard to go from SQl-based to native tables, and that is right of course. However, we wish to go from native tables to SQL-based. In the end your are STILL right as long as we all see that what we wish for is far more easy than the other way around.
>I commented on this because I myself read your above lines wrongly. IMO the below just IS applicable. If you don't agree upon my comments on the above lines, please explain a bit further, because appearently I then don't understand.

Peter,

First, I was basing this on my personal experience in moving from using native VFP data to SQL Server. Naturally, I want to leverage as much of the existing code as possible. I picked this particular example, however, in light of my own circumstances. I have to do a lot of retrieval of data from other tables, and because of business considerations, have to bring them into another table. There are over a dozen applications that do this.

I personally don't beleieve that going from SQL Server tables to VFP is any harder than the other way around. There are just different considerations that should be made.