We don't do sprocs or CursorAdapaters: there's no significant speed advantage over remote views. We design in xCase, and then move it to our framework of choice. xCase, with a little munging for our metadata, generates the SQL (either drop/create, or synch).

The PK constraint and unique constraints are in SQL; all the rest is in our VFP-based metadata. Scaling apps where everything is running on the backend is acknowledged by the "black belt" SQL gurus to be problematic.

Everything worth parameterizing is done. We have custom Find dialogs to collect the parameters, using the metadata to provide the user with intelligent choices.

There's replication, and there's replication, if you know what I mean. But, if you put your user udf's in user data, and you're talking about replicating the database to other offices (who are not hooked into a central SQL database), then I'd much rather keep it in VFP. Of course, there are UDF's and there are UDF's, if you know what I mean. A lot depends on what you mean by a UDF. If they can be "anything" then a blanket approach won't work, of course.

Hank

>I have a few questions.
>
>How do you like Fox as your UI/middle as opposed to you using a .Net platform.
>
>Do you guys do Sql pass-thru's or CursorAdapters?
>
>How many sprocs? ( How much backend processing versus middle )
>
>How many round trips are you making to get the data you want in the business tier?
>
>We are a very heavily meta data driven app and thus do a lot of function calls to build all our view queries and other queries at runtime.
>
>We also allow the user to dynamically add udf's to the database and feel the management of that in SQL will be harder since we replicate to remote users.
>
>
>
>Thanks for answering.