Running a Command

This page assumes you have a working profile (see Setting up a Profile) and that set_profile --test <PROFILE> --what all passed.

The two commands you'll use most are:

Both share the same connection plumbing — once set_profile --test --what connection passes, both will work.

isqlline — single SQL command

Use isqlline for ad-hoc queries: row counts, schema spot-checks, sanity checks before a deploy.

Syntax

The first positional is the SQL command itself (quoted), the second is the database, the third is the profile name or alias.

Examples

Quick row count:

[Screenshot: terminal showing the isqlline command above and its result row]

Schema check:

Output to a file (suppress console):

[Screenshot: terminal showing isqlline -O output, including the options.out file content after]

Notes

1. Argument order matters. SQL is first, profile is last. isqlline atlas SRM_LOCAL "select 1" will fail or query the wrong thing — the parser treats positionals strictly left-to-right as (Command, Database, Server).
2. isqlline does NOT write to the changelog (ba_gen_chg_log) by design — it's for ad-hoc queries that shouldn't pollute history. Use --changelog to opt in.
3. Override credentials per-call with -U / -P if you need a different login than the profile's default. A :port suffix on the profile name (e.g. MYPROFILE:5001) overrides its stored port.
4. -MSSQL / -SYBASE / -POSTGRES overrides the platform autodetect (rarely needed).

runsql — execute a SQL script

Use runsql to compile a stored procedure, install a table, or apply any multi-statement script.

Syntax

Examples

Install a table:

Compile a stored procedure:

[Screenshot: terminal showing runsql output for a stored-procedure compile, with line-by-line progress]

Useful flags

[Screenshot: terminal showing --preview output for a script that uses &dbpro& placeholders, with the resolved version printed]

bcp_data — bulk copy table data

Use bcp_data to copy the contents of individual tables out of a database into flat files, or load them back in. It is the managed replacement for the classic export_sql_table_data / import_sql_table_data scripts — bulk copy runs inside the tool on all three platforms, so no native bcp client is needed. Each table maps to one data file named after the table (<table>.bcp) in the current directory.

Syntax

Table names come first (one or more), then the direction, then the profile — always last.

Examples

Export one table (writes options.bcp to the current directory):

Export several tables at once, mixing resolved and fully qualified names:

Load a table back from its data file (reads options.bcp from the current directory):

Notes

1. IN is destructive. The target table is truncated before the load, then bulk loaded from the file, then statistics are refreshed (update statistics, or analyze on POSTGRES). Make sure the .bcp file holds the data you want before importing.
2. A bare table name is resolved through table_locations — the same &table& placeholder mechanism the other compilers use — so the database is chosen for you; run it where your profile's SQL source resolves (a RAW-mode profile skips resolution). A name containing .. (e.g. sbnmaster..options) is used exactly as given.
3. Importing into Innovative's canonical source server is refused — the tool detects it by profile name and exits before opening a connection. Export is always allowed.
4. With multiple tables, a failed table does not stop the run — the remaining tables still copy, and the exit code is non-zero if any table failed.
5. -O <file> captures the run log, as in isqlline. The table data itself always goes to the per-table .bcp files.

A typical workflow

A compile-and-verify cycle for a new stored procedure:

1. Preview the resolved SQL to confirm placeholders will substitute correctly:

`` runsql my_proc.sql sbnpro <YOUR_PROFILE> --preview ``

1. Run the script:

`` runsql my_proc.sql sbnpro <YOUR_PROFILE> ``

1. Verify with a quick query:

`` isqlline "select 1 from sysobjects where name = 'my_proc'" sbnpro <YOUR_PROFILE> ``

[Screenshot: terminal showing the three commands in sequence, with output of each]

When something fails

1. Can't connect — re-run set_profile --test <PROFILE> --what connection. Common causes: rotated password, firewall, server down.
2. Wrong database — check the second positional. Compiling Atlas SQL to the srm database is silent (it just doesn't find the right tables). Use isqlline "select db_name()" <db> <profile> to confirm where you're actually connected.
3. Placeholder didn't resolve — the source has &users& etc. but --preview shows them literal? Profile is in RAW mode (see Setting up a Profile → RAW mode vs SQL source). Either flip RAW_MODE off or use a different profile.
4. Script ran but the changelog row is missing — gclog12 option is off, or ba_gen_chg_log_new is missing on the target. Both checked by set_profile --test --what changelog.

See also

1. Setting up a Profile — the prerequisite for everything here.
2. Getting Started — install + repo access.