Developing and Modifying Databases in Teams

In addition to working together with projects and project files, your team must be able to share information in databases. Working with databases as a team involves not only the issues of ordinary concurrency control for data in tables, but the need to be able to share database control information as well.

For several developers to work with a database at the same time, they must be able to share the database (.dbc) file. In Visual FoxPro, the .dbc file can be shared between developers as an ordinary data table. The .dbc file must therefore be stored centrally with the tables making up the database. Developers shouldn't keep local copies of a .dbc file because changes that they make to the database will not be reflected in other developers' versions of the file.

If you do need to change the .dbc file, note the following restrictions:

  • Developers cannot modify the same database element (such as a table structure, view, or connection) at the same time. When a developer modifies a database element, Visual FoxPro locks its entry in the .dbc file; other users can read the entry (that is, they can issue a USE command), but they cannot modify it (MODIFY STRUCTURE).

  • If a database element is in use, you cannot modify its structure. For example, if one developer has a table open, no other developer can modify its structure.

  • If you call the DBSETPROP( ) function to change the properties of a database, the function puts a write lock on the object being updated. If there's a lock conflict, DBSETPROP( ) follows the rules established with SET REPROCESS.

Working with Views and Connections

Views and connections work somewhat differently than tables. When you're first defining the view, Visual FoxPro uses the tables in a database, but doesn't lock them. However, because the tables are in use, other developers cannot modify their structures.

From the time you first save a new view or connection definition, Visual FoxPro locks it exclusively until you close the View or Connection Designer. In other words, as long as you have the view or connection open in a designer, it's locked exclusively. While the view is locked, no one else can modify it.

When you use a view, its structure is cached locally. This ensures that if the view is modified while you're using it — for example, if you call REFRESH( ) or REQUERY( ) — your form or report continues to run correctly.

See Also

Community Additions

ADD
Show: