>>I've been trying to get this to work with ODBC and SPT but if i read the VFP docs correctly a param can't be part of a SELECT statement. Anyway. so far no luck but I'm not sure it is critical to the app and seems like kind of a half assed approach to do in on the back end when it is a VFP app and the potential result set is really small anyway.
>
>You can do this one of two ways:
>
>
>

>LOCAL lnRows
>
>lnRows = 10
>SET STEP ON 
>TEXT TO lcSQL NOSHOW TEXTMERGE
>   DECLARE @RowsToGet INT
>   SET @RowsToGet = <<m.lnRows>>
>   SELECT TOP (@RowsToGet) * FROM SomeTable ORDER BY SomeField
>ENDTEXT 
>
>?SQLEXEC(m.lnHandle, m.lcSQL, "curResults1")
>
>
>LOCAL lnRows
>
>lnRows = 10
>
>TEXT TO lcSQL NOSHOW 
>   DECLARE @RowsToGet INT
>   SET @RowsToGet = ?m.lnRows
>   SELECT TOP (@RowsToGet) * FROM SomeTable ORDER BY SomeField
>ENDTEXT 
>
>?SQLEXEC(m.lnHandle, m.lcSQL, "curResults2")
>
>

Thanks, Paul. The problem is I am doing this in VFE with remote views. I did try the second approach you show above. I have not yet tested to see if the parser in VFE/VFP that converts a remote view to SPT would do the substitution at runtime. In order to convert the 900 views I wrote an app that exports all the local views to prgs using VFEGenview then gets them as close as it can to what I want by manipulating the prg as a string and rewriting it to file. Then it flags the stuff in the files that will take human intervention and I start grinding on those. Haven't put them back into a DBC yet to run them against the back end (another program will compare the results against benchmark data in SQL and in VFP in the 2 versions of the program.)

I really did tell the client it would just be faster to rewrite the app using EF, Breeze and Angular but they think somehow they are getting something by taking a very badly designed VFP app and making no changes other than to make it talk to SQL data that uses the same bad design. (sigh)