Stephen:

>Pertti, not to beat this to death but what are you doing with views in .NET anyway? Remove views in VFP are great but now that your out of the DBC, what good is all that anyway?

Not much, really. Except if for some strange reason you write your app to work against VFP databases...

>Do you use Datasets or pipelines for fetching data in .NET? In my only app in .NET I used MSDE for storage and DataSets for holding data for manipulation. How will a case tool help in this manner? I use to work with the Sybase product but am no longer affilated with that employer.

I guess views are not THAT much different from Datasets, really. You use one or the other to select data and create joins, datasets are just much better isolated from the specific backend. I would think that it would be nice to have an integrated visual CASE tool, such as xCase (inexpensive) or DataArchitect (expensive) or what have you, for datasets, too. It would at the least decrease the amount of repetitive work you have to do when setting up your data environment. It would furthermore make your design much more readable, consistent and less error prone. Additionally, it would allow you to set up "domains" that you can use to automatically generate properties for certain kinds of data.

> I just used Visio for this .NET project. Not great but it did diagrams for show to my programmer.

Visio is kind of a "dumb" diagrammer for this purpose, because (at least as far as I know) it cannot generate the actual SQL statements from your design, nor prequalify your database schema for integrity and other important rules. Without a tool you will have to debug that part yourself, manually, which is not much fun.

> Are you coding trigers into your backend?

Generally not, in order to keep my backend options open.

>You said "stuff like view generation, data integrity, default value generation, PK generation, data entry formatting and input masks, etc. becomes a breeze."

>I see this as pure GUI interaction past the intergrity item. I let the backend do my keys, I never manufacture them. Default values, when needed it's pretty easy in code to drop them in. Formating of data and input masks, never use them.

Yeah, a lot of it is GUI -related stuff. But still a pain in the keester when you do the same thing manually, over and over again... Handing stuff like default value generation to the backend is fine, I guess, except if you need to keep your app backend -independent. That's what meta data tries to do -- keep you "above" the code and backend as much as possible (when applicable), so that the end result is as flexible as possible. As for PK generation, if it is a surrogate key you are generating (as you **should**), the backend is the perfect place for that. If it is a natural key, the backend could not handle it without scripting in most cases.

> Can the VPM act like this in a Web environment? I'm just doing Web based apps in .NET.

No. They've been trying to get a "dataengine" up and running, which would be a data layer server for the web as well as Windows, but it has not materialized, at least as of yet. I've done a few West Wind/Voodoo combination apps for the web, but I experience increased resistance on the part of the web server managers when it comes to installing VFP -based servers on their boxes. So, hence I am making the move to .NET right now. I'm hoping that MM .NET will take me there faster than going it alone.

I'm by no means an expert on .NET, I'm still learning it. But, as they say, with fresh eyes you can sometimes see fresh solutions.

Pertti