You can use the MDrivenServer database validation tools to find inconsistent links and schema differences between your model and the databases used by your application.
Database validation checks data already stored in a database. It is different from data validation, which applies business rules to data entered through an application.
Before you run a check
Create a restore point before you investigate or repair reported data. A consistency report does not change data, but remediation may require database queries or object deletion. Follow MDriven Backup & Restore Guide to back up the Admin database, the running model, and model data as appropriate.
Run these checks after events that can leave the database out of step with the model, for example:
- After an upgrade or model upload.
- After resolving warnings from database evolve.
- Before moving a model from development or test to production.
- When the MDrivenServer log reports ambiguous values for a single association. See Duplicate IDs in the database.
Open database validation
- Log in to MDrivenServer.
- Select Settings and then Admin.
- Choose the validation action that matches the problem you want to investigate.
| Action | Database checked | Use it to find |
|---|---|---|
| Validate Admin DB Data | The Admin DB | Consistency problems in the MDrivenServer internal database that holds model information. |
| Validate A0DB Data | The A0DB | Consistency problems in the database that holds application data. The A0DB can be an internal or external database. |
| Column field consistency check | Database tables and model fields | Schema differences that can cause runtime failures, such as incompatible types, nullability, or insufficient string length. |
Validate Admin DB Data and Validate A0DB Data
Use Validate Admin DB Data for the MDrivenServer Admin DB. Use Validate A0DB Data for the application-data database. Each action checks the tables in its selected database and returns an error report for detected inconsistencies.
Investigate a reported duplicate single link
A single link is an association that must not have multiple source rows pointing to the same target through that link. If two rows do so, MDrivenServer can report an ambiguous association value.
For example, a report can include an identifier and a query such as:
Single link dupes(38146711), execute
select PublisherAgreementPeriodID,Count(PublisherAgreementPeriodID)
from AgreementImport
where not PublisherAgreementPeriodID is null
group by PublisherAgreementPeriodID
having Count(PublisherAgreementPeriodID)>1
The query groups non-null values of PublisherAgreementPeriodID and returns values used more than once. In this example, each returned value identifies a target that more than one AgreementImport row points to.
- Copy the SQL statement from the report.
- Run it in the query interface for the affected SQL database.
- Inspect the returned rows and determine which link is incorrect according to the intended application data.
- Correct the incorrect link without bypassing MDriven's object handling.
- Run the validation again to confirm that the issue is resolved.
Repair data safely
Do not delete a reported row directly in SQL unless you have also accounted for every reference to it. Direct deletion can leave references, aggregate objects, or link objects behind and create further inconsistencies.
A safer repair path is:
- Set the association attribute that creates the duplicate link to
nullfor the row that should no longer be linked. - Use the OCL debugger to locate the now-disconnected object with OCL or OclPS.
- Delete the object through the debugger.
Deleting through the object model lets MDriven handle linked aggregate objects, links from other objects, and link objects correctly. For the meaning of ambiguous single-link log messages and additional diagnosis context, see Duplicate IDs in the database.
Column field consistency check
Use Column field consistency check to compare the database schema with the current model. Run it after database evolution, especially when an evolve warning says that a change will not be evolved automatically.
The check reports the following differences:
| Check | What it detects | Example |
|---|---|---|
| Type | The field type in the database differs from the type in the model. | A model field has been changed to a different database type while the existing column remains unchanged. |
| Database allows null; model does not | A database column accepts NULL, but the model defines the attribute as not null.
|
The model requires a value for CustomerNumber, while its database column still permits null values.
|
| Database does not allow null; model allows null | A database column rejects NULL, but the model allows it.
|
A user clears an optional model field, but saving fails because the column requires a value. |
| Database string length is shorter than the model length | The model permits strings longer than the database column can store. | The model allows 500 characters, while the database column permits fewer characters. |
The check does not report a database string column that is longer than the model field. A longer database column is normally not a runtime problem and is harder for the check to establish.
How the string-length check works
For string fields, the check attempts an update using strings at the lengths defined by the model and then rolls that update back. If the database cannot accept the value, the report identifies the mismatch. The check is intended to reveal schema problems before a user encounters a runtime error.
Some database providers require a table to contain data before this test can execute correctly. If you expect a mismatch but do not see it reported, verify that the affected class has persisted data, then run the check again.
Resolve schema mismatches
- Read the report and identify the model class, attribute, and database column involved.
- Compare the current model definition with the actual database schema.
- Review prior database evolve messages. A message that a change "will not be evolved" means you must make that database change manually using your database server tools.
- Apply the required schema correction using the database tooling for your database platform.
- Run Column field consistency check again.
- Keep investigating until the report is clean and reports no issues.
A clean report is important because type, nullability, and length mismatches can otherwise appear only when the application reads or saves affected data.