>
>Has anyone else on UT here felt just as frustrated as I am feeling, or did y'all get over it 3 or 4 years ago while I was still making money with VFP?

I've used a similar pattern with my business objects in VFP and in .NET, so my VFP code and .NET code look pretty similar. But until you get that layer in place, yes, it can be frustrating. Especially since there are so many alternatives here.

I've used two different approaches in my code. One was a simple wrapper where you'd essentially pass SQL to the server to grab the data you were interested in. The results were returned as a DataTable and I'd have a simple wrapper class around the row of the DataTable. There was another wrapper around looking at the data table for changes and writing them back (usually using some code which would walk the DataTable to create the INSERT/UPDATE/DELETE statements as appropriate. My VFP code mirrors this approach, except replace "cursor" where you see "DataTable" in my description. For complex queries I just used native SQL or stored procs and wrapped these into methods on my business object.

On a current project I'm using LinqToSql (yeah, it's "dead", but I'm not ready to use Entity Framework yet (it seems like most of the issues/complains will be fixed in 4.0)). Honestly, I think L2S (and since EF uses LINQ, it as well) has an interface that most VFP devs would feel comfortable with. Want to do a "SEEK"? Here's what that code might look like for me:

var sample = new MySampleBizObj();
var record = sample.Context.Customers.FirstOrDefault(r => r.State == "MI");

Want to just write a query that finds customers in Michigan (basically a SQL Select) (instead of a SEEK)

var sample = new MySampleBizObj();
IQueryable<Customers> customers = from cust in sample.Context 
                        where cust.State == 'MI'
                        select cust;

I get back either a single object or a collection of objects that have properties for each of the fields. In the first example I can modify the record and save it.

record.CustomerName = "Replace";
sample.Save()

The LINQ syntax is a bit funky since it's like backwards SQL statements, but it starts to grow on you as you use it. I still find complex queries easier to write as normal SQL code, so in those cases I have methods that do that for me:

var sample = new MySampleBizObj();
var results = sample.ExecuteQuery(@"SELECT st.*,
                                                   ot.Field1
                                        FROM SomeTable st
                                        LEFT JOIN OtherTable ot
                                            ON st.ID = ot.fk_SomeTable
                                      WHERE st.FieldVal = @Key", this.CreateParameter("@Key", "SearchForMe"));

That returns a DataTable to me. I can access the rows the normal way or load the row into an entity class which wraps the row for me.

Thinks like a SCAN just become a foreach over a collection. Subqueries on L2S stuff is just as easy:

var sample = new MySampleBizObj();
IQueryable<Customers> customers = from cust in sample.Context 
                        where cust.State == 'MI'
                        select cust;

// Now grab only customers that have an "A" in their name.

var filtered = from c in customers ;
                  orderby c.Name
                  where c.Name.Contains("A")
                  select c;

You'll notice I'm not mentioning strongly-types datasets. I've used them but I don't really like the wrapper classes they generate so I tend to start writing wrappers around them so they work the way I want them to. At that point you lose some of the benefits.

Formatting on databound controls is a bit clunky. For formatting, I rely on third party controls to help with this. The native controls suck. You'll be much happier with almost any third party set of controls. You can customize the native controls, but unless your needs are really simple I think it's a better investment to just purchase a set of controls.