This is probably pretty simple to handle in a setting but I cannot remember which setting this morning.
When deploying, many of of our companies add their own fields for internal consumption to our base table fields. For their own use, by their own internal programs. Or we have older programs that do not require new fields that we are adding in newer versions. These fields are not used by our applications that we provide.
Since those fields are not in the schemas, we are getting error messages about the tables not being the same as the schemas.
What settings let us override this schema checking type of behavior?
Let me add something else since we just had this happen at a new site.
How can we disable the error that the schema does not match if a field is missing. A field in the schema was not found.
All the fields are there that we need but we made the schema from a table that has more fields than what are normally distributed. In this case, the test database has fields that are not created at the distribution level.
And we get this error if we open a database where the System table does not have the OE_GenerateEmail field. There are no fields in the System table Fields property for TDAFieldsCollection. Normally, we would have them here, but we removed them to see if that was also causing the error.
In the past, when doing this conversion, we have always tried to make sure the schemas and the tables are exactly equal, but we need to have an alternative now that we are putting these in the field where the tables are not always exactly the same as the schema.
