Leland,

Yes. MSSQL is the back end. I'm wondering if you could take a look at another thread I started - thread#683953

I posted that when I was having problems with the remote views on large data sets. In my testing, it would take 3 seconds to download 85K records (Local machine for testing - Pentium 4 - 512 megs of RAM, win2kserver), using sqlexec.

Opening the same remote view - 3 seconds before my use command would return, however, from the time the use command was executed (from the command window) until the time the view was 'truly' ready, ie. the status bar shows 1/85000, was about 3 minutes. If I attempted to do any I/O like replace, before 3 minutes, I would get connection busy errors. Using SQLExec I have no such problems. I had posed the question as to why such a difference if remote views are just a wrapper. I didn't get any definitive answers. Do you have any ideas? Have you experienced the same?

re: coding the sql strings, I wrote a little routine that uses the fields() function to create a formatted string for all the columns in a table (or view) and pastes it to the clipboard - this eliminates some of the tedium.

Also, I am using stephen sawyer's view editor - from his view editor I can copy the view definition statements to the clipboard, then paste to a prg, then, convert the dbsetprop statements to cursorsetprop statements.

Do you have the thread numbers regarding the improvements in vfp8?

Thanks for your help.



>Hi David,
>
>Are you using MSSQL as your database back-end server. I have read some posts by Ken Levy regarding improvements in VFP 8, so it will work better with MSSQL. I'm hoping that VFP 8 will eliminate the necessity of much of the code I have written, so must of the work can be done in the VFP 8 app hidden from view under the hood. SPT is a great way to access a back-end database, but coding the SQL strings is a real pain.