Skip to content

s4g853.md

Latest commit

 

History

History
119 lines (98 loc) · 4.58 KB

s4g853.md

File metadata and controls

119 lines (98 loc) · 4.58 KB

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"

See Also

AfterModifyTable, BeforeOpenTable, Database Events, Rename Connection, Rename Table, Rename View