George has some good advice, I just want to add a couple of points.

>If there is no need to create SPs at this stage (I don't know T-SQL), do >you think it is possible to build this application and learn as I go?

Possibly, depending on the current state of your application. If you rely on some of VFP's record-by-record processing (GO TOP, SKIP, etc) you will have some issues adapting the app to SQL.

I would recommend getting as familiar with T-SQL as you can, as fast as you can. You'll need it, sooner or later. Some processing is just better done on the SQL Server, rather than bringing a mess of records across the network to your client app.

>If I created tables in a database in my own copy of SQL server, once done >or complete, does SQL server allow you to "pick up" the database from one >SQL server and install it on another?

To a degree. SQL allows you to detach and attach databases, but DO THIS WITH CAUTION, as it scrambles any user rights that may have been assigned to the database. A better solution might be to make a backup of your DB and restore to the client machine.

Regardless of how you do it, once you have the DB on the production server, updates will become a big issue. Once the users start making changes, they get a little snippy if their data gets whacked. This is really where you will need T-SQL, as table changes etc. are best done via script.

Two recommendations for you:
1) See if you can find a copy of the Urweiler et al book on VFP and Client-Server (published by Hentzenwerke). There's some good info in there. Also, I did a white paper on migrating to SQL that I believe is still available on the EPS web site.
2) Depending on the eventual size and complexity of the system, I would highly recommend a third-party data modeling tool to help you handle structural changes in the DB. xCase is pretty decent and a lot more affordable than other data modeling tools, you might check that out (www.xcase.com).

Hope this helps.