Field length validation checks that text values fit the target field before loading.Advanced ETL Processor Enterprise validates field lengths inside a visual ETL workflow, rejects or routes oversized rows, logs the failure reason, and keeps the original source data unchanged. It prevents silent truncation, failed inserts, and the classic support question: why is the customer name now only half a customer name?
Length problems are common in old systems
Legacy databases often use short fixed-length fields. Modern sources do not always respect those limits. A product description from an API is often longer than the database column waiting for it.
Advanced ETL Processor validates field length before the writer step. The workflow rejects the row, routes it to an exception table, or deliberately trims values when that is safe and agreed.
Fields worth checking
Customer, supplier, and product names.
Postcodes, state codes, country codes, and identifiers.
Email addresses and URLs.
Free-text fields loaded into legacy databases.
Do not trim blindly
Trimming text is useful when it is a business decision. Cutting an internal note is usually acceptable. Cutting an account reference is how future you develops trust issues.
If this validation rule belongs in a repeatable ETL process, configure it in the Validator object, test it on a sample file, then decide whether failed rows should be rejected, logged, or routed for review.
