CLEAR SCREEN | Hackers Guide to Visual FoxPro 7.0

BeforeRenameConnection, AfterRenameConnection, BeforeRenameTable, AfterRenameTable, BeforeRenameView, AfterRenameView

These database events fire when a connection, table, or view is renamed, either programmatically using the RENAME CONNECTION, RENAME TABLE, or RENAME VIEW commands, or, for tables, visually in the Table Designer (there's no way to visually rename connections or views).

Usage

PROCEDURE DBC_BeforeRenameConnection( cPreviousName, cNewName )   PROCEDURE DBC_AfterRenameConnection( cPreviousName, cNewName )   PROCEDURE DBC_BeforeRenameTable( cPreviousName, cNewName )   PROCEDURE DBC_AfterRenameTable( cPreviousName, cNewName )   PROCEDURE DBC_BeforeRenameView( cPreviousName, cNewName )   PROCEDURE DBC_AfterRenameView( cPreviousName, cNewName )

Parameter	Value	Meaning
cPreviousName	Character	The previous name of the connection, table, or view.
cNewName	Character	The proposed new name.

As is the case with other before-and-after pairs of events, you can prevent a connection, table, or view from being renamed by returning .F. in the before events, while the after events simply receive notification that something happened.

If you rename a table in the Table Designer, the BeforeRenameTable and AfterRenameTable events fire before the AfterModifyTable event does.

If you rename a table that's open, all subsequent database events for that table (until the table is closed, that is) are passed the former name of the table rather than the new name. See the topic for BeforeOpenTable for an explanation of why this bug occurs and a workaround for it.

One from the weird side: If you rename a table visually (that is, you change its long name in the Table page of the Table Designer), VFP refuses to execute the method of an object in the BeforeRenameTable and AfterRenameTable events. For example, suppose you have code like the following:

PROCEDURE DBC_AfterRenameTable(cPreviousName, cNewName) loObject = NEWOBJECT('MyClass', 'MyLibrary.VCX') loObject.SomeMethod()

If you trace this code, you'll see the object being instantiated, but the call to SomeMethod is skipped over as if it was a comment line.

Object methods are correctly called when a table is renamed programmatically with RENAME TABLE. We can't imagine what calling methods has to do with whether a table is renamed interactively or programmatically.

One use for the before events is to ensure that corporate naming conventions are followed. For example, if the names of local views should start with "LV_" and remote views with "RV_", you could check that cNewName follows these standards in the BeforeRenameView event, and return .F. if not, to prevent the view from being renamed.

Example

* This code goes in the stored procedures of a database.   PROCEDURE DBC_BeforeRenameConnection(cPreviousName, cNewName) WAIT WINDOW PROGRAM() + CHR(13) + ;     'cPreviousName: ' + cPreviousName + CHR(13) + ;     'cNewName: ' + cNewName   PROCEDURE DBC_BeforeRenameTable(cPreviousName, cNewName) WAIT WINDOW PROGRAM() + CHR(13) + ;     'cPreviousName: ' + cPreviousName + CHR(13) + ;     'cNewName: ' + cNewName   PROCEDURE DBC_BeforeRenameView(cPreviousName, cNewName) WAIT WINDOW PROGRAM() + CHR(13) + ;     'cPreviousName: ' + cPreviousName + CHR(13) + ;     'cNewName: ' + cNewName   * End of stored procedures.     * Rename a connection, table, and view.   RENAME CONNECTION MyConnection TO MyNewConnection RENAME TABLE Customer to Customer_Table RENAME VIEW "Customers in Specific Country" TO ;     "CustomersInCountry"