Hi Gary,

I have been involved in a couple of projects like that. One was a massive commercial application and yes, it was that simple to start with. But anyone new to sql server i.e. you and some of your customers, start to hit issues. Some purely learning curve ones others just sql server issues you either didn't know or you could have done differently. It too way too long to deliver and commercially speaking it was a bad decision. It's still wrapped up nicely sitting on the shelves. It offered great experience.

The second project was smaller, less than 20 customers, we had alot more control in terms of going in to sort issues. Not too much conflicts with corporate procedures. It's been great.

I know there is usually a business requirement to solve a problem here and now. But in the idea world, I would invest into the future technology.


>We have a mature vertical market application in 150+ sites, it started in dBase and has gradually moved through to VFP9.
>
>Most (but not all) is rewritten into VFP9 OOP style with data objects being accessed from data input forms and those data objects doing the read/write. The reports are all VFP reports, based on either SQL queries to the back end data or direct reading of VFP tables.
>
>We are now experiencing major issues with;
>
>a) larger clients data slowing down due to volume of data being read across the network.
>b) issues with Server 2008 R2 (documented in other threads).
>
>Our long term plan is to move over to .Net with SQL back end (currently undergoing .Net training), but clearly that is going to take a while to complete.
>
>What I want to know is what my short term options are? Can I use the upsizing wizard and simple change my table reads to be remote views to a SQL back end? is it that simple or will that take so long to write/debug etc that I am wasting my time?
>
>Any thoughts / ideas welcome!
>
>Gary.