Table of Contents

Property ImportTransaction

Namespace
YndigoBlue.Velocity.Data
Assembly
YndigoBlue.Velocity.dll

ImportTransaction

Gets or sets whether import operations should be wrapped in a database transaction.

public bool ImportTransaction { get; set; }

Property Value

bool

Remarks

When enabled (default), the entire import operation is wrapped in a single database transaction. If the import fails at any point, all rows are rolled back and the database remains in its original state before the import started. This ensures data integrity and prevents partial data corruption.

Transaction vs. No-Transaction Behavior:

  • With Transaction (True - Default): All-or-nothing semantics. If the import succeeds, all rows are committed. If it fails, no rows are committed—the database is unchanged. Safer but slightly slower due to transaction overhead. Recommended for all production imports.
  • Without Transaction (False): Rows are committed in batches as they complete. If the import fails partway through, some rows will be committed and others will not, leaving the database in an inconsistent state. Only use this for non-critical data or when you explicitly want partial imports to persist.

When to Disable Transactions:

  • Very large imports (millions of rows) where transaction overhead becomes significant and you can tolerate partial success. Even then, ensure your application handles partial imports correctly.
  • Non-critical or reference data where partial imports don't cause data integrity issues.

Recommendation: Leave this enabled for all production imports. The transaction overhead is minimal compared to the safety benefit of atomic import operations.