Smart Client (SCSF) Membership App - Background

This post is part of a series which discusses the journey I took building a smart client membership application using Microsoft's Smart Client Software Factory (SCSF). You can navigate the entire series by going to the introduction.
My first approach was to fire up trusty old MS Access to build a single database even though I knew that sharing information wouldn't be easy yet is possible. I've used Access off and on since it was first introduced and even resurrected some screen shots (here, here, and here) using Virtual PC to run Windows for Workgroups 3.11. I had recently developed a one-off application for a friend to track customers and orders at her day spa. She first asked me to help by fixing some bugs and adding a couple of enhancements to an Access 2000 application originally written by a college student she had hired. It looked to me like this person had hacked up the Northwind sample and made it work reasonably well for her but there were a few problems - like canceling an order that was started did not return the products to inventory. In short, I took it as a challenge and opportunity to brush up my Access skills. When it was done there was a whole new application consisting of 36 tables, 35 queries, about the same number of forms and reports and a dozen modules. It took a couple of months of nights and weekends to do but I enjoyed it and felt I had a good, solid code base to work from for future projects.
Using that code base as a starting point, I figured it would be pretty easy to build on it to develop the membership system. After working out the data requirements and designing the schema I set about building the UI portion. After a while, it became apparent to me that I was asking too much of Access. Simple flat single-table screens and parent-child screens can be done very easily - lots of examples to follow! However, more complex tabbed user interfaces housing controls for many tables and complex relationships such as one-to-one and one-to-many-to-one drove me deeper and deeper into hacks and workarounds trying to get things to behave. Before long, I found myself remembering (daydreaming) how I had built similarly complex user interfaces in the past using Visual Basic 3/4/5/6 and my frustration mounted. Finally, I came to the conclusion that I was spending all my time trying to work around the tool and not solving the business problem at hand.
I then went back to square one and began looking around for a better toolset to work with. Requirements such as distributed access, offline capabilities, easy remote deployment and updating, and scalability led me to look at the SCSF toolset.
Original post