>>> Is MS SQL your only choice?
>We use MS SQL LocalDB on the client machine - The Linked Server feature is provides a very fast transfer of required data from the primary server to the local pc.
Hmmm localDB. I think that is not suggested in production, only for developer testing. Express is a better choice IMHO.
>
>>> Is C# your only choice?
>We have have large C# and VB.net code and skills base but we are open to suggestions.
>
>
>>> If it is, and you still need to execute thousands of queries, Can you utilize CLR functions in MS SQL server? Could the process be more suited to Linq?
>The queries are all built dynamically at runtime and then sent to either SQL Server or Oracle or IBM DB2 or AS400 etc BUT they can ALL be entirely different in all respects.
>So CLR in MS SQL wont really help an neither will Linq as it will just intoduce more overhead.
>
>>> can you parallelize the tasks and execute asynchronously?
>The queries do come in sequentially and need to be executed as such so tthere is little scope for paralel execution except for in the formulation of the query string
>Also we dont want to bog down the client computer too much by occupying too many CPU cores. VFP is already very agressive on the CPU.
>
>The existing VFP application performs exceptionally well.
>The only reason for the conversion is that we need a 64 bit version of our application because it integrates with MS Office and many of our users have migrated to 64bit Office.
If that is the only reason, for many things you can use VFP with 64 bits office (actually can't think a reason why wouldn't you be able to use). If you mean you are having problems connecting to VFP data from within Office applications, there might be alternatives like:
-Connect to stream or recordset instead (I utilize this technique to send data to Excel and create pivots etc. Works well).
-Use a 64 bit driver for VFP data, there is one from Sybase ADS and one from Devart AFAIK (priced a bit).
If the data itself is not VFP database then you wouldn't even need that, no?
