>Hi John,
>
>>Not a snag, but I have a curiosity question. For the database creation when you install, or to modify the tables when you upgrade a system, do you write that in c# or do you write it in SQL?
>
>Some people here will surely get a kick out of this, but we're still using an old VFP app I wrote about 5 years ago to handle our SQL database creation and updates. It uses SQL DMO. I'm sure the concept that we use for this can be converted to a .NET app, but so far we haven't had the time or resources to do it. It works great as is, and since it's strictly a server side app, it's not really an issue to deploy it for our customers (since it doesn't get to the workstations at all).
>
>What's nice about using VFP is that it's easy to keep all the database schema change scripts in a .dbf. You see, we "version" our SQL database ... every entry in our .dbf has a sequential version number and the schema change script. The SQL database has a table that holds the current version number. Whenever you update your database, it checks the most recent script change version number in the .dbf against the database's version number and only runs the appropriate scripts. It works quite nicely. A list of .sql files containing Stored Proc definitions is stored in another .dbf file and those are easy to update too ... all our Stored Procs are dropped and recreated each time.
>
>>(Edit: 1:25am PST) I just filled a typed dataset using roughly the technique you described and it worked great! I even managed to allow for the use of alternate data providers in the design.
>
>That's great! But quit working so late!!! <g>
>
>~~Bonnie

I still think VFP Rocks and I am going to miss it sorely as it fades into oblivion. But then for most of what I do (data file cleanup, data/field standardization and preparation for mailing) I still have not found a good alternative to VFP. I have major utilities and applications that I have written in VFP for this type of work, but I still spend a good deal of my time at the command prompt tweaking things in the data files to get them just right. Doing the work with just SQL would be a pain and last I looked I couldn't even find the command prompt in Access.<g> I may end up having to go back to dBase.

The c# work I'm doing is for accounting and production management, for which .Net is a excellent alternative to VFP and should be able to tie into my legacy apps pretty easily. I only get a little time to work on it each day, but a new language is always fun and I'm enjoying coding this, that's why I was up so late.

Thanks Again!