>Whitney,
>
>Remote views are a PITA if they get too complicated (I.E. joining 3 or more tables). However, I would assume that data entry occurs into 1 table at a time. Setting up a view thru the designer for 1 table is very easy. Even preferred. If you set up 1 table for updating thru code, you will have to code many DBSETPROPS to get the view correctly setup for updating.
>
>PF
>
>>Hi,
>>
>>I am exploring the possibility of setting my VFP app to work with SQL Server. I've reviewed the upsizing and client/server documentation that came with VFP6 and feel like I undestand the concepts, but I'm trying to avoid heading down the wrong path in converting my tables and databases to run in a VFP front end - SQL back end situation.
>>
>>- Should I use remote views ?? (I've heard there can be problems and not much benefit from using them).
>>
>>- Should I explore more development on the SQL side (scripts that update data etc..), or concentrate on altering my VFP app data (convert my tables to local and remote views etc...) ??
>>
>>I know its a little vague, but I was wondering if anyone that had done this before had any input.
>>
>>I would greatly appreciate any information anyone has.
>>
>>Also,
>>The tables in my app are all 10,000 records or less.
>>There are no Local Views in the application.
>>Security and Transaction Logging is not really an issue.
>>2 main goals are speed and providing data to other applications.

What Problems did you have with setting up a remote view with more than one table for updating? The reason I ask is that I haven't had any problems utilizing more than one table in a view that was updateable. I beleive the largest view definition I am using is 4 tables with creating/setting indexes prior to dbsetprop on setting the buffermode.

Pat.