Hi Matt,

I use exclusively DBC containers and not a single free table.
So here are some tips;

1. Keep DBC table and belonging tables in a same folder
it will spare you of lot of troubles.

2. Comming from free table environment, don't get to high right away
on MS RI builders and persistent relationships. Without some major changes in yr logic you might face lot of problems. If you want RI constrains then look for some 3p RI builders rather than what comes out of the box.

3. Coversion to DBC should be straight fwd, so don't consider it big issue.
Simply drop yr free tables into the same directory , create dbc
and then add them all to it without any changes in index structure.
Feel free to add captions.
In first phase of 'conversion' you should get everything to work
without any changes to existing code except maybe for path handling
when you are opening tables in custom method. If free tables are scattered
arround then server then paths should change accordingly.

Once you get app to work smooth with DBC container , then you can do what ever you are pleased. Maybe venture into implementing transactions, some well designed RI handlers etc.

But in general, provided that app is working fine as you said
even what you are doing now is sort of uncalled for. I wld rather use that time to learn and adopt some CS architecture/aproach and then
port your VFP data directly to some enterprise level RDBMS.

Only twds that goal, what you are intending to do might be good idea.
But rather then messing with live data, create offline copy of those
free tables, then create proper VFP DBC with all tables, put RI etc in place
and then use it to test upsizing into RDBMS and creating paralell CS
solution.

As you probably know VFP can handle very efficiently forests of databases and data, so unless your organisation shows clear thrend of overgrowing level
of 'heat' that VFP can take, (and that is a lot of heat) I don't see point in doing even that just for a sake of it. As some people here wld say; Don't 'fix' it if it aint broken.

HTH







>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)
>
>
>
>
>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.
>
>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.
>
>
>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.