My $.02, since I'm being otherwise unproductive today:

>All in all, I find the whole concept of DBC "events" peculiar: if you're going to go to the trouble (as a programmer), why not just use SQL Server and have "real" events and procedures ?

For the middle-tier. Client requests hit the web server, the data-centric business logic gets passed to the VFP COM object. Having events in the DBC lets me make some "massaging" changes to certain columns as they get written to tables. Now no matter what method is firing, I always get the properly "massaged" info into my rows. Every n process or every n minutes, the data gets read from the local tables, cut into MSSQL2K Updategrams and passed to MSSQL2K behind the firewall (slowly streamed to as not to choke the back-end). I'm a pretty firm believer in making the database server just do data and not business rules (compare the text manipulation features of T-SQL and VFP or even VBScript, T-SQL isn't quite up to it). The SQL server is taking thousands of hits from all over the place per n minutes (my internet-based app and intranet stuff) and it's better to get correct stuff into MSSQL in the first place without having stored procs and triggers fire for every insert. All the transactions are faster. Plus the full-time DBAs don't get annoyed with us developers affecting server performance with single-threaded T-SQL or cursoring or etc. DBA's can be DBA's and programmers can be programmers.


>DBC's, etc. are just more walking sticks for people who like the "old" (or cheap) way of doing things.

Cheap != bad. I was putting together an e-commerce framework for small retailers over a year a go, and the pricing for VFP ($0) compared to MSSQL ($n per user and/or $n for the internet connection or $n per CPU) made it a no-brainer. If you want to sell a product for $5,000 you can't include the MSSQL , it just costs too much for the small-mid business. And doing something like MSDE doesn't necessarily fit either because if the database lives on the same server as the web server you have to deal with another layer of security complexity (port 1433, etc) not to mention issues with backups, tuning, etc. which a small e-tailer is not also wiling to pay for. I am thinking that during this general economic slowdown, a VFP-centric solution would have more weight compared to MSSQL (again for small/medium implementations) on sheer implementation price alone.

I don't see a DBC as being "old" any more than I see an MDB as "old", they're just ISAM ways of coping with data issues.