Matt,
A long question. I'm writing reply dispersed in your question.

>I am wanting to make the move from the free-table structure to a dbc database container on my company's main app that I've been developing on for years.
>
>Here's what I've got to work from:
>
>VFP 9.1
>
> - Native vfp tables with CDXs and some tables have memo fields
>
> - Every form uses private datasession and modeless state.
>
> - Each form calls a custom "open_data()" procedure in his load event to open the required tables, set order, and relations for that form
>
> - Buffering (TableUpdate) is used to save changes
>
> - 12 years of experience (but all with free tables)
>

You meet the prerequisities (hard word to spell correctly).

>
>
>
>I would appreciate any general (or specific) commands, advice, and things to look out for as I begin.
>
>
>
>One specific question I have about the DBC approach is this: in one form I may use "Table_A" as the parent to "Table_B" child, but in another form, I need to reverse that and use "Table_B" as the parent to "Table_A" child. So, I am wondering how I will handle this since I think in the DBC model you set all your relations there. Do I choose one layout as the default, and then re-arrange the relations in form.load()? Or is this where the "views" come in and maybe I need to pull a view with an alias and set it all up from there? I do not know anything about views yet, but I have fair SQL knowledge, so maybe that will help. Just need some insight before I start.

In DBC you set persistent relations. You are not bound to set any relations even if logically there is, but set them. Despite having persistent relations there they have no direct effect on your tables. They do not really guarantee any referential integrity or such. They more serve as a diagram of table hierarchies.
You may have customer - orders realtion over cust_id but that doesn't restrict you creating any other type of relations. ie: a form might be use orders to customer relation as you described (more common for reports if you ever do w/o cursors). Or it can use an orders to customer relation that's never planned before (I don't know why but maybe a temporary relation from bill_to to address in customer).

You can even have something like:

Customer - > Orders - > Customer (use again)

As per the views, if you learn you would use them as you see fit but (set flamesuit on) you wouldn't miss much if you never learned them (set flamesuit off).

>
>Also - I am guessing that in 2-5 years down the road, I may migrate the app from VFP to Visual Studio (very slowly and several years from now), so I thinking that after I get the DBC conversion done, I may begin to migrate from native VFP data to to SQL server for my data store, so that I will be in a position to begin developing in Visual Studio and calling against SQL server. I know that VFP has a VFP-to-SQL conversion/upsize tool to make the conversion, but I do not know if it is the recommended way to make the move, or if I am better off building the SQL server data store from scratch. So, as I build my DBC, I want to do it in a way that will help the SQL conversion one day. I do not know If I will ever upgrade the VFP app to run against SQL server, because that will be a ton of work that I could just invest in migrating the app to Visual Studio.
>

I haven't seen nor tested the latest version of upsizing tool but tried older versions. I ended up creating my own upsizer codes, partly in VFP and partly in T-SQL and .Net. If you could afford it timewise creating them from scratch on SQL server would be the best IMHO. Conversion to SQL server + .Net might be much simplier than you're afraid of (maybe a little optimistic but tomorrow I have a plan like this: Create 5-10 tables of our current DBC from scratch on SQL server (both table and field structures would change so upsizing, DTS,SSIS wouldn't be able to do that anyway. I already created their Visio versions so that part is considered as done in a few minutes), get data from existing sample data files using some .Net code (not written yet), create biz model classes (I use Devforce for this because my migration is not only about going from VFP to .Net. targeted distributed enterprise+smart client/web in one go), create a few ASP.Net pages. I think it'd be done in 3-4hrs and would be more or less functional as what I could do with VFP in the same time frame using ready DBC - of course I could create those ASP.Net pages in an half hour or so if directly used existing DBC but that's only the initial part of the real migration to test some prototypes).

>
>Now then... would anyone recommend to just leave it like it is with the free tables and be happy? It is rock solid right now, but I just thought It would be a more professional, solid, cool, fun, "real" VFP app if it was based on DBC instead of free tables. I may be just wasting a bunch of time, but I am young (40 yrs old) and love a good VFP challenge, plus I thought it would help with preparing to move to SQL Server.

Well if it is rock solid, then "do not touch" would be a wise suggestion:) Converting to DBC is very easy and might take only 5 minutes. OTOH it wouldn't be more professional, ... but maybe fun. In a DBC or free it is a real VFP app anyway. DBCs have some advantages but if you don't need them it is your sole decision to do it or not.

I like you're saying that you're young at 40. Then I can still be considered as young too:) If you like challenges then here is one for you:

Create a database (or use testdata.dbc)
Run home()+"tools\gendbc\gendbc" to get its programmatic version.
Study its code.
Backup your data and on a copy create a DBC version of it (remember I said it would take 5 minutes to convert - and I guessed you might have over 100 tables:)
Of course plain converting and taking full advantages of DBC are not the same thing but then you can put a slave worker in front of the monitor and request him/her to do more if you wouldn't do all in code (but again you'd be preparing yourself writing migration code to SQL server as an exercise).
Cetin