>>2. What is the tool Naomi pointed you to? I could be forever in debt to her, too ;-) (Actually I already am, but never mind).


Mike - Yes Sergey and Naomi are just terrific, aren't they?.

Check out SP_gen. If you can't find it, email me and I'll send it.


>>3. To be honest I am skeptical that conversion of xBASE data commands to T-SQL compliant code will be less daunting than I expect. It won't be rocket science but there are enough differences to make the prospect seem, uh, interesting. This app (these 67 apps) make extensive use of FoxPro concepts like SEEK, SCAN, COPY to temporary tables, and the like. The less I have to touch this code the happier I'm going to be. It feels like poking a tiger with a stick.

For sure, but once you get your hands into them, there's room for creativity.
Some low volume reference tables rarely change, but are read from all over the place, so we changed those apps to load them from SQL server tables into dbf cursors when the apps loaded and just left the old code as it was, using the cursors as if they were native dbf's. It's a kludge but it saves a lot of work on code that will shortly disappear anyway.

Good luck Monday!




>We''ve done a few of these. I'm up to my neck in one now.
>There are really two conversions - one to SQL server and one to .NET
>We use a table by table approach to the SQL Server conversion and use SQL passthru with stored procedures at every step.
>That allows you to use those same STP's with .NET later.
>Changing VFP's apps to use SQL tables instead of DBF's isn't as daunting a task as it seems, if you plan it judiciously.
>There will be a period - as long or as short as you want it to be, while your VFP app uses both DBF's and SQL Server tables.
>
>The Upsizing tool sucks, so I've written some VFP tools that facilitate moving the data from DBF's to SQL Server.
>
>Naomi pointed me to a great tool that generates Insert, Update and Query STP's for a SQL Server table and that tool cuts days off the task of creating the STP's.
>I'm forever in debt to Naomi and the author of that tool. It's a lifesaver!!!!!
>
>Once the data has been converted to SQL Server, we've used a module by module approach to moving from VFP to .NET code, working with the client to chose the functions that would benefit most from .NET features or which need updates for other reasons.
>The client considers things like the personnel involved, the location of the users, etc and we contribute the technical information about which modules can be most readily developed.
>In some cases, the client was so anxious to move a function to .NET that we used VFP and SQL data in the .NET app because the VFP data wasn't slated for conversion to SQL Server for a long time and the client needed the new functionality in a hurry.
>
>I wrote a .NET code generator that generates and passes parameters to the STP's and that cuts even more days off, because writing the .NET code yourself can be verbose and it's error prone.
>
>Typically it's taken over a year to get a decent-sized app moved over.
>
>Planning it out carefully with the client and developing some tools to handle the mechanical tasks can make this a lot simpler than it seems.
>

This is right on target with the situation I am facing. Thanks, Bill.

A few specific questions and responses --

1. Not the point here but I have had much better luck with the Sedna upsizing wizard than the one in VFP 9. It did the job, albeit slowly.

2. What is the tool Naomi pointed you to? I could be forever in debt to her, too ;-) (Actually I already am, but never mind).

3. To be honest I am skeptical that conversion of xBASE data commands to T-SQL compliant code will be less daunting than I expect. It won't be rocket science but there are enough differences to make the prospect seem, uh, interesting. This app (these 67 apps) make extensive use of FoxPro concepts like SEEK, SCAN, COPY to temporary tables, and the like. The less I have to touch this code the happier I'm going to be. It feels like poking a tiger with a stick.

I have faced similar situations before, what I call Igor Left Syndrome. By that I mean legacy FoxPro apps which were written by developers who are no longer in the picture. Some of the apps were bad, some competent, some quite good. There was never as much information as you would like but through diligence and the kind of instinct for where to look that comes from experience I have always muddled through. This one is a lot scarier in terms of both scope and code style. I told my manager that if a developer wanted to write software that was incomprehensible to anyone but the original coder, this is exactly how he would do it. As just one example, table names and variables frequently have illuminating names like L01, L02, L03. (Actually I figured that one out -- line 1, line 2, line 3 on an address label -- but it wasn't with any guidance in the names).

The adventure continues Monday morning <g>. Thanks again for your advice.