BeforeDropTable, AfterDropTable, BeforeRemoveTable, AfterRemoveTable

These database events fire when you remove a table from its database. The BeforeDropTable and AfterDropTable events fire when you use the DROP TABLE command, while the BeforeRemoveTable and AfterRemoveTable events fire when you use the REMOVE TABLE command or remove the table visually using the Database Designer.

Usage

PROCEDURE DBC_BeforeDropTable( cTableName, lRecycle )
 
PROCEDURE DBC_AfterDropTable( cTableName, lRecycle )
 
PROCEDURE DBC_BeforeRemoveTable( cTableName, lDelete, lRecycle )
 
PROCEDURE DBC_AfterRemoveTable( cTableName, lDelete, lRecycle )

Parameter	Value	Meaning
cTableName	Character	The name of the table to remove.
lRecycle	Logical	Indicates whether the RECYCLE clause was specified in the command.
lDelete	Logical	Indicates whether the DELETE clause was specified in the command.

Okay, the first thing to get out of the way is: Why are there two sets of events? The simple answer is because there are two sets of commands that remove a table from the database. REMOVE TABLE came along first (it's been in VFP since version 3.0), while DROP TABLE was added in VFP 5.0 because it's the ANSI-standard command. Fair enough. But still, why do we need two sets of events, given that the net effect of both commands can be the same (the table removed from the database and possibly deleted from disk as well)? Frankly, we don't know. After all, there are separate DELETE VIEW and DROP VIEW commands (for the same reason as the two table commands), yet only one set of BeforeDropView and AfterDropView events. We do know, however, that if you need to know when a table is removed from its database, you'll need to put code in both sets of events, even if they simply call a common routine (a good idea).You can prevent a table from being removed by returning .F. in the Before events, while the After events simply receive notification that a table was removed.One use for the AfterRemoveTable event is to handle the case where a table is removed from its database but not deleted (hence this won't involve the AfterDropTable event), making it a free table. If the table has long field names that are used in index expressions, you'll get a "Variable LongFieldName is not found" error when you open the table. Since free tables don't support long field names, they're all converted to their 10-character equivalents, which make the index expressions using the former names invalid. To fix this problem, you simply have to re-create the indexes. By doing this in the AfterRemoveTable event, you'll prevent the problem before it ever occurs.

Example

* This goes in the stored procedures of the database.
 
PROCEDURE DBC_BeforeDropTable(cTableName, lRecycle)
WAIT WINDOW PROGRAM() + CHR(13) + ;
    'cTableName: ' + cTableName + CHR(13) + ;
    'lRecycle: ' + TRANSFORM(lRecycle)
 
PROCEDURE DBC_AfterDropTable(cTableName, lRecycle)
WAIT WINDOW PROGRAM() + CHR(13) + ;
    'cTableName: ' + cTableName + CHR(13) + ;
    'lRecycle: ' + TRANSFORM(lRecycle)
 
PROCEDURE DBC_BeforeRemoveTable(cTableName, lDelete, lRecycle)
WAIT WINDOW PROGRAM() + CHR(13) + ;
    'cTableName: ' + cTableName + CHR(13) + ;
    'lDelete: ' + TRANSFORM(lDelete) + CHR(13) + ;
    'lRecycle: ' + TRANSFORM(lRecycle)
 
PROCEDURE DBC_AfterRemoveTable(cTableName, lDelete, lRecycle)
WAIT WINDOW PROGRAM() + CHR(13) + ;
    'cTableName: ' + cTableName + CHR(13) + ;
    'lDelete: ' + TRANSFORM(lDelete) + CHR(13) + ;
    'lRecycle: ' + TRANSFORM(lRecycle)
 
* End of the stored procedures.
 
 
* Create a table, and then remove it using REMOVE TABLE.
 
OPEN DATABASE TestData
DBSETPROP(DBC(), "DATABASE", "DBCEVENTS", .T.) && Turn events on.
CREATE TABLE TestTable (Field1 C(10))
USE
REMOVE TABLE TestTable DELETE
 
* Create another table, and then remove it using DROP TABLE.
 
CREATE TABLE TestTable2 (Field1 C(10))
USE
DROP TABLE TestTable2