The operational problem
Your process receives CSV files in Amazon S3, but moving them to SQL Server means repeating decisions about formats, columns and destinations. A changed delimiter or invalid amount makes the load less predictable and the table contents harder to explain.
Moving rows is only part of the task. You need an agreed file structure, an identified table and evidence that loaded values meet the process contract.
How Dova helps
Dova can read a CSV stored in Amazon S3 through Object storage input and connect it to Database output for SQL Server. The Mapping selects connections, object, format and destination; the Session provides execution context and a compatible worker.
A Workflow invokes the Session and Monitor lets you inspect the attempt. Separating design from context helps retain a reusable load. This use case starts with a file already available in S3 and an existing SQL Server table; final acceptance includes querying the table and comparing its contents.
How it works
Agree on the CSV and table
Define headers, delimiter, UTF-8 encoding and compatible types. Place a synthetic sample in an authorized S3 bucket and prepare an existing test table.
Configure both connections
Prepare read access to the S3 object and a SQL Server username/password connection. The destination account needs table write permission; keep credentials in the intended mechanisms.
Design the Mapping
Connect Object storage input to Database output. Select the S3 object, CSV format, delimiter and fields; configure the SQL Server connection, schema and table with Append for the first trial.
Bind the context and run
Publish the Mapping and configure a Session with the intended worker and parameters. Publish the context and execute a laboratory Workflow with authorized permissions.
Verify the load
Inspect the attempt in Monitor and compare rows, keys and values in SQL Server. Define how to recognize a repeated batch before loading it again.
What you need
- A CSV already stored in Amazon S3, with a nonempty header, unique field names, UTF-8 encoding and a known delimiter.
- Authorized connections: read access to the S3 object and SQL Server username/password authentication, with an existing table and write permission.
- An eligible worker with S3 and SQL Server dependencies, connectivity and secure transport; permissions to publish and execute.
Limits to consider
- This case starts with a CSV in Amazon S3. It does not describe loading directly from a file uploaded in the browser or from a local path into SQL Server.
- Append can insert the rows again when a batch is repeated. Key handling and reconciliation belong in the process design.
- The table must already exist: automatic creation is not assumed. Windows integrated authentication, Kerberos or Azure tokens for SQL Server and performance at any volume are not promised.
Demonstration example
Illustrative example using synthetic data. This is not a customer result or a product screenshot.
Demonstration: sales from an S3 object
Store these two synthetic rows in an object in an authorized laboratory bucket. Configure that source and a compatible test table. The expected path is CSV in S3 → Dova → SQL Server. Compare both keys and amounts afterward; this is not presented as a completed load.
sale_id,amount
DEMO-001,125.50
DEMO-002,80.00