From iDataView to SQL Warehouse addresses a problem most SAP landscapes know too well: Stale warehouses and failed night jobs undermine dashboards the C-suite already promoted.
The SQL Project Cockpit defines source objects, target tables, field mapping, delta parameters, and schedules — monitored in SQL Job Monitor with package-level error detail.
SQL Transfer moves SAP data to MSSQL or PostgreSQL using project-based jobs with methods I (full refresh), A (append), U (upsert), D/L (delta), package sizing, and parallel processing.
Capabilities you use in iDataEngine
- Connection test from the maintenance screen
- First Row Test and Package Error Data popup
- SQL Job Monitor with cron schedules
- MSSQL and PostgreSQL dual-engine parity
- Package size and parallel processing
- Methods I, A, U, D, L with delta parameters
Recommended workflow
- Open the relevant cockpit (iDataView Explorer, SQL Project, API Service Detail, or AccessGuard).
- Configure source objects, fields, mappings, or rules using session language and customer/system context.
- Enable monitoring alerts and review dashboard KPIs for the first production cycle.
- Run Test (iDataView Test, SQL First Row, API Test Service, or AG scan) before scheduling or publishing.
Real-world scenario (2024)
E-commerce stock sync every ten minutes via upsert into PostgreSQL — website stays fast when SAP is slow because SQL Transfer owns the cache layer.
Why it matters
Dual-engine parity means you are not locked to one DBA religion — architecture stays portable while jobs stay monitored the same way.
Innovation here means business sees results faster — IT keeps control because every step is configured, tested, and monitored.