Toni Feltman - Square Peg, Round Hole - Retrofitting Client Server Data Access into Legacy FoxPro Applications

Toni started by letting us know that this session was for people working with VFP apps (not 2.x apps) that need to move from a VFP back end to some other back-end, such as SQL Server, Oracle or any other back-end.

Toni pointed out that it is important to set goals. Up front, the team needs to agree on why you're changing back-ends, what you hope to achieve, and a timeline - taking into account things that are likely to cause you trouble.

Toni suggested that once you pick your data source (And It think maybe even as part of the decision making process) you should become well versed in the tools that you'll be able to use to manage and manipulate your new data source.

Related to that, Toni strongly suggested hiring an expert to get your new database up, running and properly configured. I think this is good advice as even after working with SQL Server for six years I know next to nothing about proper configuration or performance tweaking.

Next, Toni discussed the issue of actually moving the data. She discussed the various approaches of moving or converting the data such as VFP's Upsizing Wizard. (This was mentioned twice this week as being a good tool for moving data from VFP to SQL Server. Toni mentioned that several of the third party tools can convert data much faster than a custom-written VFP app. I didn't realize this and I hope I remember it on my next conversation. We've had several in the past that were very time consuming.

Toni also pointed out that this is the time to decide whether or not to redesign the database. She correctly points out that we rarely design a database correctly the first time, nor is it likely that changes applied to our databases have been done according the best practices. If you have a reasonable timeline, this should be considered an opportunity to redesign your database. If you're on a short timeline, you're likely to need to create an identical design in the new back-end.

Toni reviewed the different approaches we can take to access our new back end such as Remote Views, Cursor Adapters, SPT, and Stored Procedures. She walked us through code examples all but Stored Procedures.

Toni suggested several approaches for getting reacquainted with our legacy code so that we can look for the things that will need to change for the new back end.

Perhaps one of the most important issues Toni raised was that you must have a reproducible process for data conversion. You're going to need to convert over and over as you retrofit your code. You'll need to be able to get clean, live, production data into your new back-end on a regular basis. This is something I also learned from working with Rick Schummer and Steve Sawyer and I couldn't agree more. Nearly every application we develop starts with writing a conversion routine.

Toni wisely instructed us to make sure you can completely disconnect from Production Data – hard coded paths and things like that can really bite you. Toni suggested setting up a virtual machine without a connection to the network drives.

Then, Toni suggesting reviewing you code for commands that are specific to you old style of data access such as USE and SET ORDER. (Using Andrew MacNeill's Code Analyst from VFPX will probably make this a breeze.)

Toni also discussed the very important issues relating to how different back-ends store data differently than VFP, particularly when dealing with NULLs, empty strings, logical, (and I'd offer dates, too.) I have to admit, that I've changed code to handle these issues instead of taking Toni's much smarter approach of creating a library of methods to handle this data once instead of each time you come across it in your code. (I think her approach would also make it easier for you to retrofit a vertical market app for multiple back-ends.)

Toni also mentioned that you should start testing right-away - as soon as you have something to test. This will help to uncover problems earlier in the process instead of later when it will be more costly to address.

She also suggested that you should really try to avoid new development during this process. Adding new features should be pushed off until after the migration is successful.

As usual, Toni gave a well prepared and well presented session with great ideas.