Datamine DataBlast 2.14: Keeping Blast Design and Field Records Connected

A drill-and-blast plan loses much of its value when the office cannot reconcile it with the holes drilled, conditions measured, and work recorded on the bench. DataBlast’s most useful evaluation question is whether it can preserve that chain for the site’s actual equipment and reporting process.

This research-based technical assessment uses official documentation checked on 8 November 2026; DataBlast has not been independently installed or tested.

Datamine’s current documentation catalogue identifies DataBlast Pro and DataBlast Ignite 2.14. Both address open-pit drill and blast, but their deployment roles differ: Pro is a multi-user system with field capture and a reporting data source, while Ignite is a standalone desktop solution with the same design tools and provision for field data. That distinction should drive the shortlist before a feature comparison.

Keep the design connected to the field record

The 2.14 help organizes the workflow into Design, Drill, Measure, Charge, Initiation, and Firing modules. A representative evaluation would trace one approved pattern through surveyed geometry, recorded drilling and measurements, execution data, and the reports returned to engineering. Hole identifiers, units, coordinate references, timestamps, and revision status must remain consistent across those handovers.

DataBlast’s role is downstream of the mine-design basis. Our Surpac assessment discusses geological models and design inputs, while the MineScape assessment addresses connected design and scheduling. These are complementary stages, rather than direct substitutes for a drill-and-blast record system or evidence of certified connectors between particular builds.

The Initiation manual documents electronic and non-electric system design, firing simulation, and exports to named electronic initiation systems including DaveyTronic and Orica i-kon. A buyer should verify the exact supported device/software pair and the information exchanged. A simulated sequence or vendor statement about safety does not independently establish an acceptable field outcome, vibration prediction, or design approval.

What the 2.14 evidence actually establishes

The 2.14 release notes were published on 1 September 2026; the public release announcement explains the same release family. This is the latest public version verified here. The exact latest maintenance build remains a vendor confirmation item; the old draft’s 2.10 description should not be presented as current.

Version 2.14 moves to .NET 8 and bundles required runtime prerequisites. It adds separate export of vibration-analysis tables, timing-contour direction arrows, and custom-property controls including fixed-value lists, numeric limits, and visibility of resolved expression values, including Null. Those documented changes matter for data review: an analyst can examine a calculation’s inputs and export the relevant table without treating an attractive contour display as validation.

The release notes also describe repairs to stale average burden and spacing values on CAD print borders and changes concerning custom expressions and field data. Before an upgrade is accepted, compare representative stored patterns, printed reports, calculated properties, and field exchanges. The notes identify specific changes; they do not provide an independent benchmark of accuracy, speed, or fragmentation outcomes.

Choose Pro or Ignite against the site’s data responsibilities

The Pro 2.14 requirements describe application-server, SQL Server database, workstation-client, and BlastPad-client roles. They also specify low-latency server links and recommend scoping the infrastructure against anticipated data growth. A central multi-user installation therefore needs an agreed owner for databases, access, upgrades, backups, and field synchronization, rather than being budgeted as one engineer’s desktop installation.

Ignite fits a single-machine deployment more directly. The cumulative release notes date its transition to SQLite to version 2.10: new site databases use SQLite, and restored LocalDB databases are converted. That history is useful when evaluating an existing installation, but it is not a substitute for testing restoration and data handover using the selected 2.14 installer.

Licensing changes are equally consequential. The July 2025 section of the cumulative notes introduced Pro Starter with one workstation and selectable capabilities such as reporting and drill import, alongside Pro Core. The notes also say neither Core nor Starter includes a BlastPad device license by default, despite describing Core as including all features. Treat server support for a capability and the entitlement for an actual field device as separate questions. Ignite is described there as one license per machine with one user at a time; confirm current seat, term, offline, and transfer conditions in the order.

Verify integration at the object and permission level

The versioned release history documents named interfaces, including WencoMine in 2.10 and Sandvik OptiMine in 2.12. Those entries establish interface development, not automatic compatibility with every current drill fleet. The external-systems prerequisites require appropriate database/file access for the DataBlast service and installation user; Windows integrated-security connections require the relevant domain-account permissions.

The reporting database, selected custom properties, and hole-pattern exports are useful integration surfaces, but the sources reviewed do not establish a general supported API contract. Ask the vendor to demonstrate the exact planned-versus-actual field mapping, handling of duplicate or changed hole IDs, synchronization conflicts, and failed imports. These are acceptance criteria, not defects observed in this assessment.

Use the requirements for the edition being purchased

Ignite 2.14 requirements list 64-bit Windows 10 or 11, 16 GB RAM, 100 GB storage, .NET 8, and an OpenGL-compatible graphics card with at least 1920 × 1080 display resolution. Pro’s client and server tables differ. Its documented server OS and SQL Server lists include older releases; ask Datamine to confirm the current supported and maintainable configuration rather than infer support for newer versions or ignore lifecycle constraints.

For a combined Pro application/database server, the manual says to add the role requirements and gives an example of 8 cores and 32 GB RAM. This is vendor baseline guidance, not a capacity result for the reader’s site. Confirm database size/growth, network latency, field connectivity, high availability, remote or virtual deployment, and security configuration in an implementation study. Datamine’s support portal requires customer access and maintained licenses; a public help page alone does not establish the support entitlement purchased.

A meaningful alternative comparison follows the same blast

Maptek BlastLogic is a relevant direct alternative over the shared design-to-execution and reconciliation workflow. Its official page documents design revision control, field QA/QC, charging/timing records, and reconciliation of planned, actual, and downstream data. Compare how each configured system represents the same hole records, revisions, field exceptions, device interfaces, and reporting responsibilities. Maptek identifies BlastMCF as an optional scenario-generation add-on; it should not be assumed to be part of every BlastLogic configuration.

The current supplier is Datamine, with the 2.14 help carrying Datamine Corporate Ltd copyright. Constellation’s 27 July 2015 announcement records the acquisition of Datamine from CAE into Vela, and Vela’s portfolio continues to list it. No separate current DataBlast rebranding was verified.

DataBlast merits evaluation when an open-pit team needs a controlled connection between design and field records, particularly where Pro’s shared data roles match the organization. Ignite may be sufficient for a single-machine workflow; another system may fit better when its verified device interfaces and reconciliation process align more closely with the site. Evidence is strongest for the 2.14 workflow, edition architecture, and explicit release changes. The next useful step is a representative round trip through the purchased modules and actual field interfaces, with every revision and report traceable to its source.