---
title: "JDBC Deployment"
canonical: "https://docs.vaultspeed.com/space/VPD/3013804059/JDBC%20Deployment"
format: markdown
---
Automatic Deployment of generated code using JDBC links is available in the application in the “Automatic Deployment” menu.

This will use the agent to deploy the generated DDL/ETL code found in the zip files that your agent downloaded.  If your agent hasn’t downloaded the zip file yet, the button for automatic deployment will be disabled.

- For DDL and SQL ETL it will connect to the database using the credentials defined in the chosen VaultSpeed DB link list.  The code is executed on that database using that specific user, this requires a user that is allowed to create tables, constraints, indexes, grants, and comments.
- When using remote journaling with remote delta views enabled, then these should be generated separately in order to use the auto-deploy.
- For Oracle Data Integrator it will execute the groovy scripts locally which then deploy your mappings in the ODI repository specified on the cloud app.

> ⚠️ When deploying through JDBC, make sure your DDL deployment is finished before starting the ETL deployment.  They cannot run in parallel because the ETL might rely on objects that need to be created by the DDL first.

There are some things to notice before using this automatic deployment on certain target technologies:

- Automatic Deployment of ETL code to **Google BigQuery **is only possible using the custom script, since the BigQuery code consists of SQL files instead of procedures that need to be deployed. So this script could commit the generated files to version control and/or copy the files to the scheduler code repository (e.g. Airflow). Note that the views do have to be deployed.
- Automatic deployment of **Talend** code is only possible using the custom script method at this moment.
- Deploying **Oracle** code requires SQLPlus.
- Deploying to **ODI** requires Groovy and ODI to be installed ([Installing Groovy](https://vaultspeed.atlassian.net/wiki/spaces/VPD/pages/3128856512))
- Deploying to **Databricks** notebooks requires some extra settings in the agent connections file.  A Databricks connection has to be defined as containing the following elements:
  - *connection_name.token*: Your personal access token: [https://docs.databricks.com/dev-tools/api/latest/authentication.html](https://docs.databricks.com/dev-tools/api/latest/authentication.html)
  - *connection_name.host*: The hostname of the Databricks instance, has to include '[https://'](#)
  - *connection_name.path*: The path to the root folder where the code should be deployed, has to start and end on '/'. The notebooks will have the same folder structure as the files in the zip.
  - *connection_name.ddl_deploy (execute/notebook/both)*: Determines how the DDL files should be deployed. If this is "execute" then the DDL will be executed with Spark JDBC (this is the default), if it is "notebook" then the DDL code will be deployed as a notebook in Databricks through the API, if this parameter is "both", then both types of deployment are executed.
  - *connection_name.trim_extension (true/false), Optional Parameter, Default value = false:*  When this is added with the value “true”, then when the notebooks are pushed to Databrciks, the name of the notebook will not include a .sql or .scala extension.

```
connection_name.token= "..."  
connection_name.host="https://....azuredatabricks.net"  
connection_name.path="/vaultspeed/"
connection_name.ddl_deploy=both
connection_name.trim_extension=false
```