Database Container

(Updated: 2006.06.26 06:05:53 PM)

Edit -Find- Recent Changes Categories Road Map [A-F] [G-P] [Q-Z] New Topic Home

Database Container (DBC) is a VFP table that is used to define a database. The table uses the file extensions .dbc/.dct/.dcx for the table/memo/index files respectively.

Like any other tool for organizing data, a database is used to organize tables, relations, and views into a cohesive unit.

In order to support the DBC the table header structure was modified to add a backlink to the DBC name. This makes VFP tables unusable natively from FP2.x and other older tools. See the help topic Table File Structure.

The CREATE/MODIFY DATABASE commands are used to define the database.

What does a DBC buy you?

Database Container Benefits	Free Table Benefits
A centralized data dictionary. Definitions of persistent relationships. Definitions of connections to remote data sources. Definitions for Local Views and Remote Views. Referential Integrity, through the Referential Integrity Builder. Triggers for insert, update and delete operations. Record and field validation rules (cuts both ways). Field default values, captions, comments, input masks, format properties. Mapping of UI control classes to table fields. Long field names (up to 128 characters). Database events (new for VFP7). VFP Transaction Support. (Note that starting in VFP 9 we have `MAKETRANSACTABLE()` for free tables) DBC is extensible, see for example GenDBCX. Persisitent relationships defind help the VFP View Designer, Data Environment, and various VFP Wizards, and document the database.	Simplicity. This is killer. Compatibility (backward and outward). Record and field validation rules not in the DBC. VFP Transaction Support in VFP 9 onwards with `MAKETRANSACTABLE()`.
Database Container Downsides	Free Table Downsides
Keeping DBC and tables in synch (structures, indexes) Updating structures on deployed systems. Portability -- relative and non-relative paths are hard-coded. No control over the timing of validation rule execution. Must provide code in apps to deal with these run-time validation errors. DBC-defined relationships don't measurably benefit your code as much as it helps parts of the VFP IDE (see Persisitent relationships benefits above). Scalability beyond, say, 50 users. See Creating DBC for Views.	Short field names (up to 10 characters). No Triggers. No Record validation. No Field validation. No default field values. No events. No field or table comments. No stored procedures. No VFP transaction support (prior to VFP9)

With thanks to Mike Lewis

Category Data

When a system design calls for multiple cohesive sets of tables, relations, and views then I use multiple database containers to organize them.

A single DBC doesn't scale because when views are opened, this momentarily locks the view records in the DBC. Not generally noticeable with say 20 or fewer users, but above fifty, it helps to have a DBC for views kept locally. See CreatingDBCforViews-- Steven Black

Every few years I take a tilt at databases and run away, because of some unexplained behavior. This time it was, if you update a table, views based on that table don't update, they just break. This was so inconceivable to me that I was sure I had done something wrong. It wasn't until I browsed through the Stonefield docs (see below) that I found out this was a "known" behavior and not a bug (at least, not a bug in the sense that the software authors were rushing out to fix it).

Whenever I create or modify a view I use GENDBC to store the DBC code toa prg. I then open the prg and comment out the code that creates the tables. If I modify a table and my view breaks I just run the prg to recreate the views and any triggers, stored procedures, indexes etc Shawn White.

Also, it seems databases grow and never shrink. There is a PACK menu item for databases but it's always greyed out. I got curious about this, deleted most of my database features (in a copy) and it got no smaller. So I USEd it ... it has 656 records according to reccount() but only 65 according to count. Yet none are deleted. I think this is done with indexes, but I'm not sure.

In what version(s) did you observe this 'feature'? Randy Bosma

Any time a tool does weird stuff like this I'm hesitant to trust it.

I would have put this into the table but I'm not sure about these things - they seem too odd to be true. Michael Wagner

6 for both. Specifically 6 SP5. Just got 9 last night and haven't installed it yet. However, I did notice in 6, when snooping around with dbgetprop(), that those views that are broken seem to have forgotten which tables they are based on. I don't know when or how that happened. Thankfully I don't happen to use those views ... I put them there for testing some view months ago ... but I do have a couple of others that I do use and they haven't forgotten their heritage (yet).

BTW, here's the message:

Base table fields have been changed and no longer match view fields. View field properties cannot be set (Error 1542).

And I can't edit the view to fix whatever the problem is. That's if I go in through the database designer. However, if it's part of a project and I go in through the project manager, I get a different message,

View fields have been changed. The Update and Key field properties have been reset to the default values (Error 1568)

And then I can edit it. Just browsing quickly, it seems fine and intact. So I don't know what's going on. And that makes me nervous. Michael Wagner

The error your report should affect only views defined with SELECT *. If you list the fields in a view, you shouldn't run into that problem.

As for PACK always being disabled, try opening the database EXCLUSIVE.--TamarGranor

Tamar: you are correct, of the 3 views that failed, one contains a select *, the other two a descendents of the first one. It still seems to lack a certain robustness, though. I was able to edit the first one, although I haven't tried to actually correct the problem yet. I feel silly about my second problem - of course the menu pad for packing the database was greyed out because I didn't have the database exclusive. I should have thought of that myself.

Category Data Category VFP Commands Category VFP IDE Category Exam 70-155 Hot Topic

Edit -Find- Recent Changes Categories Road Map [A-F] [G-P] [Q-Z] New Topic Home

http://fox.wikis.com - a low-impedance, fat-free Visual Foxpro site.

- 2010.09.08 10:01:38 AM EST