Cases Where Failed ALTER TABLE Doesn't RevertLast reviewed: September 18, 1995Article ID: Q136851 |
The information in this article applies to:
SUMMARYThis article describes circumstances that change the table structure even if the ALTER TABLE command fails.
MORE INFORMATIONIn general, any failure reported by either the ALTER TABLE command or the MODIFY STRUCTURE dialog box should result in the source table remaining unchanged from its state prior to the action. One exception to this is when a new primary key is created or an existing key is promoted to being a primary key. An error message is displayed if the key creation fails because Visual FoxPro detects a duplicate key. However, all other changes to the table remain intact. The SET SAFETY ON/OFF command also affects some of the validation performed by the ALTER TABLE and MODIFY STRUCTURE operations. The following information applies to the table validation rules, table validation text, field validation rules, field validation text, and field default values. Regardless of the setting of safety, the syntax of the information entered is validated. However, if SAFETY is ON, then the information is also evaluated before any attempt is made to alter the table. Therefore, setting SAFETY ON provides an extra level of validation that can occur even if the the NOVALIDATE clause is used to avoid a lenthgy rule verification phase. Example: For a field rule for FIELD1 where MEMVAR1 is not in scope:
ALTER TABLE Table1 ALTER Field1 CHECK Field1 !=memvar1 NOVALIDATEThis succeeds if SAFETY is OFF, but fails evaluation because MEMVAR1 is not in scope. NOTE: If a user-defined function (UDF) is recognized during the validation phase, the function is not called and the validation passes.
|
Additional reference words: 3.00 VFoxWin sql
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |