Connect a source to the right project and see which operations its driver supports in that environment: metadata, previews, queries, transfers, writes, deletion and quality checks. A connection alone does not make every operation available.
Data operations
Turn data from separate sources into repeatable work.
Explore connected databases, prepare files and tables, and arrange supported transfers and quality checks. Keep the definition, run status and recorded outcome together when the work is repeated.
Use SQL Console to explore the selected source within project permissions, read-only rules and result limits. Named tabs preserve drafts with autosave and checks for concurrent changes. Save a useful query, turn it into a dataset or prepare it for visual analysis.
Upload a file or import it from a secure URL and retain its original version and checksum. Before a transformation is queued, inspect the content, separators, quotation marks, headers and detected structure.
Load validated CSV, delimited UTF-8 text, JSON records or the first XLSX worksheet into a new table version. Its stable name points to the new version only after validation succeeds, so an incomplete import does not replace the current table.
Combine supported SQL execution, query and direct transfers, schema transfers and transformations, deletion, quality checks and orchestration. Each start has a saved run record. Older stored job types outside the current catalog do not become supported automatically.
Keep queued, running, failed, partial, canceled and recovered outcomes distinct. Losing contact does not prove that a write failed. Cancellation, retries, rollback and duplicate prevention are not universal guarantees; use least-privilege database roles and the recovery procedure supported by each operation.
Know what each connected source can do.
Connect a source to the right project and see which operations its driver supports in that environment: metadata, previews, queries, transfers, writes, deletion and quality checks. A connection alone does not make every operation available.
Explore data without losing the query you are preparing.
Use SQL Console to explore the selected source within project permissions, read-only rules and result limits. Named tabs preserve drafts with autosave and checks for concurrent changes. Save a useful query, turn it into a dataset or prepare it for visual analysis.
Once a valid source and SQL request enters execution, its successful or failed outcome is saved with the execution record.
A saved query remains editable. Creating a dataset from it adds a separate, controlled data asset with a reference to its origin.
Read-only checks and SQL comment handling follow the selected source dialect, not PostgreSQL rules applied to other engines.
Check a file before it changes a table.
Upload a file or import it from a secure URL and retain its original version and checksum. Before a transformation is queued, inspect the content, separators, quotation marks, headers and detected structure.
Inspect CSV, TXT, TSV, PSV, DSV, DAT, DATA, LOG, JSON and XLSX according to their format.
Text with another extension can use the delimited-text import when inspection of a limited sample confirms that format.
Review the separator, control characters, quotes and escaping, header choice, sample rows and warnings before confirming.
Resolve duplicate filenames and table aliases explicitly, with a saved record, rather than overwriting an existing item silently.
Keep the current table available until its replacement is ready.
Load validated CSV, delimited UTF-8 text, JSON records or the first XLSX worksheet into a new table version. Its stable name points to the new version only after validation succeeds, so an incomplete import does not replace the current table.
-
Check the input
Confirm the file version, size, checksum, reading format and row structure before loading.
-
Prepare a separate table version
Build the replacement separately while the current table remains available under its stable name.
-
Load and review the result
Record row and column counts, structure and limited samples. An incomplete load cannot become the current table.
-
Publish only the validated version
Switch the stable name after validation. On failure, retain the previous version and the record of the attempted import.
Prepared tables are available in SQL Console through the project's System Sandbox source and schema.
Renaming and restoring a table are recorded changes. Restoring an earlier version may also restore its earlier structure.
Arrange repeatable work from supported operations.
Combine supported SQL execution, query and direct transfers, schema transfers and transformations, deletion, quality checks and orchestration. Each start has a saved run record. Older stored job types outside the current catalog do not become supported automatically.
Arrange jobs, waiting periods and quality gates in order, with serial or parallel batches.
Continue from recorded child-job outcomes in a new run, without rewriting the original history.
A definition change creates a fixed job version. Manual starts, schedules, retries and child jobs record the chosen version before dispatch.
Each future scheduled run selects the current version after fresh access checks. Preventing duplicate effects and undoing changes still depend on the operation, connector, policy and demonstrated retry safety.
See what completed and what still needs review.
Keep queued, running, failed, partial, canceled and recovered outcomes distinct. Losing contact does not prove that a write failed. Cancellation, retries, rollback and duplicate prevention are not universal guarantees; use least-privilege database roles and the recovery procedure supported by each operation.
Next step
Start with the flow that cannot afford ambiguity.
Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.
Discuss a critical flowIn brief
What does this part of advanexus do?
Explore connected databases, prepare files and tables, and arrange supported transfers and quality checks. Keep the definition, run status and recorded outcome together when the work is repeated.
What should I check before using it?
A future schedule occurrence pins the then-current JobVersion after fresh admission checks; exactly-once business effects and rollback still depend on the executor, connector, policy and proven idempotency.