Skip to main content

Version 3.1

The 3.1 line covers all 3.1.x releases. Newest at the top.

3.1.6 (21 October 2026)​

Changesets and check for changes work together: a component you pull rows into keeps a checksum of the rows it now holds, so it no longer reads RE-EXTRACT, and extracting it no longer throws your changeset away.

What's new​

  • Changesets keep their checksum. Pull My Changes, Apply Draft, Delete Changeset and the MCP pull_task_rows record the checksum of the rows they write. When the document ends up holding exactly another document's rows (you took every row on offer, or a delete put the file back as committed), that checksum is reused. Otherwise the database the rows came from, or the connected database for a branch or a draft, computes it over the document's own rows. Nothing is written to the database's own tables. At the next check the component reads UP TO DATE or CHANGED, and the pull's results say so if no checksum could be recorded. Cancel while the checksum is computed stops only that: the rows you ticked are still written. See Changesets keep their checksum.
  • Update Checksum. A new item on the component context menu gives the selected components, or every one that reads RE-EXTRACT, the checksum of the rows their documents hold, keeping the rows, then checks them again. Use it after a merge or an edit, where extracting would replace the rows you mean to deploy. It shows its progress where a check does and can be cancelled. See Update Checksum.
  • changes --update-checksums. DataStar.Tools does the same from a pipeline before it reports. See Keeping merged rows.
  • Run Changeset SQL. A component with a changeset can run it against the open connection or one you choose, committing or rolling back (rolling back by default), without putting it in a deployment first. It is the script a deployment runs, with its checks. View Rollback SQL and Run Rollback SQL move under a Rollback submenu. See Running a changeset without a deployment.
  • RE-EXTRACT says what to do. Its reasons, the warning that an extract deletes a work item's changeset, and the MCP check_for_changes description point at Update Checksum. An agent is told to ask you rather than extract.

Fixes​

  • A pull no longer leaves a component reading RE-EXTRACT. A changeset pull wrote the document without a checksum, so it read RE-EXTRACT, and extracting it deleted the work item's changeset.
  • An agent's pull clears the app's verdict. After pull_task_rows, the Changes column no longer shows UP TO DATE or CHANGED for the document it replaced.

Notes for upgrading​

  • Some Oracle values cannot be hashed from a document: a TIMESTAMP WITH TIME ZONE value, a TIMESTAMP(8) or TIMESTAMP(9) value, a BLOB over 2,000 bytes, and text over 4,000 bytes (2,000 characters for NVARCHAR2). A component holding one gets no checksum from a pull or Update Checksum, and the message says why; extract it instead.
  • A template changed since the workspace file was extracted still needs an extract: its rows are another query's.

3.1.5 (18 October 2026)​

See which components an environment has changed, without extracting anything: in DataStar, from an MCP agent, and from a pipeline.

What's new​

  • Check for changes. A data template can set TrackChanges="true". Extracting its components then records a checksum of their rows in each document, and Changes on the tab's toolbar asks the connected database for the same checksum. A new Changes column says, component by component, UP TO DATE, CHANGED, RE-EXTRACT or NOT CHECKABLE. Nothing is extracted, and thousands of components check in seconds. A document compares with every environment it has been deployed to: constants, audit columns a deployment leaves alone, and lookup ids are left out of the checksum, the lookups' criteria compared instead. See Checking for changes.
  • The Changes tab. Workspace → Changes lists every component whose template tracks changes, across categories, so a whole workspace can be checked against an environment in one go. Only changes hides what is up to date, and Only basket narrows it to your basket. See The Changes tab.
  • Verdicts follow the connection. Switch from DEV to PRD and back, and DEV's verdicts come back, with the time they were reached. They last until DataStar closes.
  • check_for_changes for MCP agents. An agent can ask which components differ from an environment, and its verdicts appear in the Changes column as it runs. See check_for_changes.
  • datastar --command-name changes. DataStar.Tools checks a workspace against a database from a pipeline: report the drift, fail a build on it with --fail-on-changes (exit code 2 for drift, 1 when nothing could be checked), or bring the workspace up to date with --extract. See changes.
  • Files under an older naming are tidied, not listed. When the workspace's file naming rules change, DataStar remembers the components' old file names as it next opens the workspace, and a file under an old name is no longer shown as a component of its own. The banner offers to delete it when it holds what the component's current file holds, or to rename it when it is the component's only file; one that holds other rows is left for you. A copy you make yourself is listed as before. See Files under an older naming.

Fixes​

  • One component, one row. DataStar's own workspace database could hold two rows for one component: one under its file's current name, and one under the name an earlier file naming rule gave it. The component could then show the old name, so Open said the file did not exist and DB Pull wrote the old file again. When it opens a workspace, DataStar now drops such rows, or moves them to the current name when the component has no other.
  • Menus of many templates fit on the screen. The Templates and Components menus use as few columns as they need, at most 20 rows each and no taller than the screen. 49 templates used to take seven columns of seven, too wide to reach the far ones.
  • bit values in SQL Server scripts. A bit was written as True or False, which T-SQL does not accept, so such a script failed when it deployed. It is now written 1 or 0.
  • A key renamed only in case, in a changeset. A child row whose own key changed only in case was recorded in a way the deployment could not apply. Each column is now compared the way the script compares it.

Notes for upgrading​

  • Extract once to start checking. A document extracted before its template set TrackChanges="true" reads RE-EXTRACT until it is extracted again. Recording a checksum needs SQL Server 2016 or Oracle 12c or later.
  • DataStar.Tools changes --extract needs a licence key, as release does with reversal.

3.1.4 (15 October 2026)​

Saved database connections that are kept safe, in one list with yours and the workspace's. Branch mode now always follows HEAD, and large adds to a deployment no longer hang. There is no 3.1.3: it was held back for the git fix below, and 3.1.4 follows 3.1.2.

What's new​

  • One list of connections, each Mine or Workspace. The connection dialog and Manage Database Connections list your own connections and the workspace's together. Each has a Workspace or Mine pill, and a workspace connection you have not signed in to yet also shows No sign-in. A name used in both scopes is listed twice and noted, rather than one hiding the other. See Your connections and the workspace's.
  • A name in both scopes no longer changes what you connect to. Auto-connect and the connection dialog remember the connection you chose, not its name, so a workspace connection that takes the same name no longer quietly points them somewhere else, such as production. When you open the workspace, A Name In Both Scopes says what each such name opens. Anything else that goes by name, such as MCP agents and deployments, opens the workspace's connection, and list_saved_connections lists only that one. See When a name is used twice.
  • Share with workspace and Make mine move a connection. Share with workspace now moves one of your connections into workspace.json rather than copying it. The new Make mine moves a workspace connection back to your own list, with your sign-in, and takes it out of workspace.json. Both remind you that the team gets the change only once workspace.json is committed and pushed. See Sharing connections with the workspace.
  • A connection missing from the workspace can be restored. A discard, a pull or a branch switch can take a workspace connection you have used out of workspace.json. When that happens, DataStar says so once, and Manage Database Connections marks the connection Missing, with Restore as mine and Forget. If the connection comes back, your sign-in is used again. See When a connection is missing from the workspace.
  • New connection in the connection dialog. New connection is the first entry in Saved Connections and clears the form, so you can add a connection even when every saved connection is the workspace's. If you have typed into the form, it asks first.
  • Save from Manage Database Connections without connecting. Add opens a blank form with the vendor to choose. Add and Edit now have Save instead of Connect, so you can save a connection while its server cannot be reached. Changing a workspace connection's shared details asks first.
  • Forget sign-in. Manage Database Connections can forget your sign-in for a workspace connection without touching the connection itself.
  • Renaming a connection keeps everyone's sign-in. Workspace connections get an id in workspace.json, and each person's sign-in is kept against it, so a rename only changes the label.
  • Changesets chip. A category tab whose template deploys changesets shows a Changesets chip at the right of its toolbar. It shows your work item and how many components on the tab have a changeset for it, or an orange dot and No work item. Click it for an explanation of deploying changesets and a Pull My Changes... button. See The Changesets chip.
  • Branch mode follows HEAD. Opening a Branch-mode deployment file stamps its items with HEAD without asking and without marking the file changed. The header shows a Follows HEAD chip. Move to HEAD and the HEAD Has Moved dialog are gone, and Compare with Latest and Update to Latest are not offered in Branch mode. Deploy, What If, Database Snapshot, SQL Export and Export Reversal Script read HEAD again first. If HEAD cannot be read, they refuse to run, instead of running at an older commit. See Pinned and Branch mode.
  • Branch-mode JSON files name no commit. Items in a Branch-mode deployment.json carry no version. A Branch-mode deployment.xml keeps one on each item for older readers, and a comment at the top of the file says so. The format hint in Workspace Settings suggests JSON for Branch mode. See File format.

Fixes​

  • Saved connections are no longer lost.
    • databases.json is written in one step.
    • Before a write that would leave fewer connections, the file is backed up. Three generations are kept: databases.backup.json, databases.backup.1.json and databases.backup.2.json.
    • A file that cannot be read is set aside as databases.unreadable-<date>-<time>.json, and the newest usable backup is read instead. DataStar says so on starting, rather than showing an empty list.
    • A save from one DataStar window keeps what another open DataStar changed in the meantime.
    • The connection dialog no longer saves on every Connect and Test, and connecting no longer deletes saved connections that its dropdown did not list.
    • See Where connections are kept.
  • Connecting with the name of another connection of your own asks before writing over it.
  • Forget sign-in sticks. It also removes the copy of your sign-in that 3.1.1 and 3.1.2 kept in user-settings.json, so the sign-in is not taken over again.
  • Adding many items to a deployment no longer hangs. This applies to the release workflow, Add Components, basket adds and file-system adds. A busy overlay with Cancel is shown, and cancelling changes nothing. Adding more than 200 new items asks first (Add Many Items). Undo after an add also restores the commits the add moved. See Adding many components.
  • The release workflow adds the right versions. A file that two commits in the release touched now takes the later commit, and adding from commits only ever moves an item to a newer commit. When there are no commits to add, the workflow offers only the basket items not yet in the deployment file. Items are matched by component at any version. When they are all there already, it asks nothing. See How the file is filled.
  • Selection commands follow the selected row. Compare with Draft, Open Draft, Apply Selected, Discard Selected and the other selection commands update as soon as a selected row changes. For example, a draft can be created from another tab, by MCP or by the startup draft check. You no longer need to click off the row and back. Reloading the grid keeps the selection. Find Dependencies and Find Referencing Components results offer the data document and changeset commands.
  • The deployment grid keeps its selection through Move Up, Move Down, Undo and Redo, and its row commands follow the selected row.
  • Git no longer stops responding after a commit. Cancelling a git read at the moment it was let in could leave git locked for the rest of the session. Every later git operation then timed out, with Timed out after 00:01:00 waiting for writer release in the log, until DataStar was restarted. It was seen after a commit in the release workflow.
  • Background tabs no longer overwrite the status bar's selection count.
  • The .NET cryptography packages are updated past the October 2026 security advisories.

Notes for upgrading​

  • Update everyone who shares a Branch-mode JSON file, and your pipelines. A Branch-mode deployment.json saved by 3.1.4 cannot be read by DataStar or DataStar.Tools 3.1.0 to 3.1.2, which report has no version. Install DataStar.Tools 3.1.4 in pipelines that build such a file, or keep Branch-mode files in XML until everyone has upgraded. Older Branch-mode JSON files still open. XML files and Pinned-mode files are unchanged for every reader. See DataStar.Tools.
  • Your sign-ins for workspace connections move to databases.json. On first start, DataStar takes over the sign-ins that 3.1.1 and 3.1.2 kept in the workspace's user-settings.json, and leaves that file as it was.
  • Update everyone on the workspace. DataStar 3.1.1 and 3.1.2 can read the new databases.json, but they drop the connection ids and your sign-ins for workspace connections when they save it. A 3.1.1 or 3.1.2 save of workspace.json also drops the connections' ids. The newer version then links each connection by its name, or failing that by where it points. See Using different versions of DataStar.

3.1.2 (14 October 2026)​

Edit and rename shared connections from the app, and data documents that stay the same when the data has not changed.

What's new​

  • Edit a saved connection. Manage saved… gains Edit (or double-click a connection), which opens the connection dialog on it so its details can be changed without typing them all in again. On a workspace connection the shared details can be changed too, and go back to workspace.json for everyone; your password stays yours, and so does a username of your own. See Managing saved connections.
  • Rename a workspace connection. Rename now works on shared connections as well as your own. The connection is renamed in workspace.json for everyone, and your sign-in, auto-connect and remembered pulls follow it. Sign-ins are kept by connection name, so a colleague who saved one for it enters it once more after taking the change.

Improvements​

  • Re-extracting a data document changes nothing when the data has not changed. For templates with OutputFormat="json": a document no longer keeps values that no script reads: a column the template leaves out (Include="false"), or one the script works out on the target (CurrentDate, a %...% expression such as %SYSTEM_USER%, or Increment). It still lists the column and its type. A source that restamps such a column, a last-modified date say, no longer shows every row as changed. Documents written by earlier versions are read as before. See Store data as documents.
  • Rows come out in the same order every time, in .sql data scripts and data documents alike. After the template's SortOrder, rows are ordered by their key and then, unless that key is the table's own primary key, by every column that can be ordered, so rows the sort leaves tied no longer swap places between extracts. A SortOrder on a column whose value differs between databases, such as a lookup's id, orders by what identifies it instead (the lookup's columns, or the parent row's key) in the same place.
  • Regenerating a changeset with nothing different leaves the changeset file as it was, rather than giving it a new captured time.

Fixes​

  • Choosing a shared connection no longer warns "The workspace has a connection of this name; choose it from Previous Connections."
  • The note under a shared connection says your sign-in is saved only when there is one to save, not for Integrated Security or Kerberos.
  • In the connection dialog a shared connection's name and description are greyed out like its other shared details, rather than looking editable.

Notes for upgrading​

  • Some data scripts and documents come out in a different order, once. This applies to .sql data scripts as well as data documents. The first extract with 3.1.2 can list the same rows in a different order (and so give a script a different hash) where the order used to depend on the database: rows the template's SortOrder left tied, a SortOrder on a lookup's id or a key joined to a parent, and tables keyed by something other than their own primary key. The rows themselves, and what the script does, are unchanged. Extracting every data category once after upgrading, and committing that on its own, keeps the reordering out of later reviews.
  • Data documents lose the values no script reads, once. Data documents only (OutputFormat="json"); .sql data scripts are not affected. The first extract of a document whose template leaves out or computes a column removes that column's values from its rows; nothing a script does changes.
  • After editing a template's columns, extract again before pulling. Changeset templates only, which are always data documents. Changing a column's Include, CurrentDate, Increment, or a %...% Value, changes which columns a document keeps values for. Pull My Changes then refuses a document extracted before the edit until it is extracted again, as it does when a template gains or loses a column.

3.1.1 (12 October 2026)​

Database connections the whole team can share, without sharing a password, and fixes to changesets and data scripts on both SQL Server and Oracle.

What's new​

  • Share database connections with the workspace. A connection can now be kept in the workspace's workspace.json, so everyone who opens the workspace has it under the same name without typing in the server and database. A password is never shared: the first time you connect, DataStar asks for yours and keeps it encrypted on your computer, in your own settings for the workspace, along with any Oracle wallet or TNS admin folder. A username can be the team's or each person's own. Share with workspace in Manage saved… moves one of your connections into the workspace; commit workspace.json to share it. See Sharing connections with the workspace.
  • When a name is used twice, you are told. A workspace connection is what its name opens, ahead of one of your own of the same name, for the connection dialog, auto-connect and MCP agents alike. On opening the workspace DataStar lists any name used twice and offers to open Manage saved…, which shows a banner until yours is renamed or removed. See When a name is used twice.
  • Rename a saved connection. Manage saved… gains Rename for your own connections.
  • Describe a connection. A connection can say what it is for, such as production, read only. The description shows under the name in the connection dialog, in Manage saved…, in the status bar's tooltip, on the Database: menu item and in the disconnect dialog, and list_saved_connections gives it to MCP agents with whether each connection is shared.

Improvements​

  • Tick changeset rows in bulk. The Pull My Changes row picker gains Tick All, Shift-click to tick a range of rows, and Space or right-click to tick the lines selected in the compare. See The row picker.
  • A confirmation's warning wraps instead of being cut off at the edge of the dialog, as the Delete Connection warning was.
  • workspace.json keeps what it does not know. Settings written by a newer DataStar are kept when this one saves the workspace, rather than dropped, and the file keeps the line endings it has, so a save on Linux or macOS does not show as every line changed in a Windows team's repository.

Fixes​

Changesets:

  • Start Again no longer loses a changeset you cancel. Pulling from a branch or a database when the work item already has a changeset used to undo the changeset before the row picker opened, so cancelling it, or a tick being refused, left the work item with no changeset and its rows put back. The changeset is now undone only when the new rows are written, in the same step.
  • The app and an MCP agent pull the same rows. Starting from a branch or a database, the row picker kept the workspace file's value for a row your source had changed too, where an agent took the source's. Both now take the source's value wherever it changed the row, and say when the workspace file held a third value. An agent can also keep a row only the workspace file changed, which it was not offered before.
  • A row changed only in columns the template never updates cannot be ticked. It was recorded, then deployed as already applied, so the target never got the value. The picker now says why it cannot be taken.
  • Combining two work items' changesets refuses a row the second puts back. A row one work item changed and another changed back was dropped from the combined changeset, so a target that already had the first kept its change. The release is refused instead, naming both, so they are deployed separately.
  • Lookup hashes are kept for rows that go back to the base, when pulling against a branch or a database.

SQL Server:

  • Unicode text arrives intact. Text outside the database's code page, such as Ωmega, was written as a plain literal and arrived as Omega or ?; a lookup by such a name found nothing and left the column empty. It is now written as N'...'.
  • datetime2 keeps its seventh digit. A datetime2(7) value was written to six, so every changeset row holding one was a conflict, and snapshots wrote it short.
  • A lookup by a date works. A lookup whose key is a date, datetime or datetime2 wrote the date unquoted, and the script failed.
  • A key renamed only in case deploys. A changeset renaming a string key of a table's own only in case (abc to ABC) failed on the primary key on a case-insensitive database. The key is now respelled in place, with the child rows that carry it.
  • Counts and cascades on case-sensitive databases. The script recorded its changes as INSERT, UPDATE and DELETE and read them back as Insert, Update and Delete. On a case-sensitive database every count read 0, and a Version 1 script deleting a parent left its child rows behind.

Oracle:

  • An alternate key changed under the same id is applied. On a table with a primary key of its own and an alternate key, changing the alternate key wrote nothing while reporting success, and a snapshot deleted the row.
  • Every changeset refuses a case-insensitive session. A session set to compare text case-insensitively took a value changed only in case for the same value and wrote nothing. The check ran only when a key changed in case; it now runs for every changeset.

Notes for upgrading​

  • Some generated SQL Server scripts change. Regenerated scripts differ from 3.1.0's in these places only:

    • text with a character beyond ASCII in a Unicode column gains an N prefix;
    • a datetime2 value has seven fractional digits;
    • the summary lines spell INSERT, UPDATE and DELETE in capitals, so the script's hash changes too;
    • a changeset with a string key of its own gains a respell step.

    On a case-insensitive database each script does what it did before, apart from the fixes above. Oracle scripts are unchanged.

  • Update everyone on the workspace to 3.1.1 before sharing connections. DataStar 3.1.0 and earlier open a workspace with shared connections as usual, ignoring them, and DataStar.Tools builds from it as before. But an earlier DataStar that saves Workspace Settings writes workspace.json without its connections; committed, that takes them away from everyone, until the commit is reverted. From 3.1.1 on, a later DataStar's settings are kept.

  • Using an earlier DataStar on the same computer forgets the passwords you saved for shared connections (you are asked for them again), and the descriptions of your own connections.

3.1.0 (1 October 2026)​

Data as documents rather than scripts, changesets for shared tables, and a CLI that builds a deployable package straight from source control.

What's new​

  • Store data components as documents instead of scripts. A data template with OutputFormat="json" commits its rows as a .json data document and generates the MERGE when it deploys. A pull request then shows a row added and a row changed, rather than a rewritten SQL script, and two people editing different rows of the same component merge cleanly. The SQL that runs is unchanged, and a document carries the part of its template that shapes the script, so it inflates with no template folder present. See Store data as documents.

  • Deploy only your rows, with changesets. On a table several people work in at once, extracting the component gives you everyone's work in flight. A template with DeployMode="changeset" records only the rows your work item changed, as before and after pairs, and deploys only those. Each row is checked against the target before it is written, so a row somebody else has changed since stops the deployment and names the rows instead of overwriting their work. Deploying the same changeset twice changes nothing the second time, which is what makes it safe to promote from DEV through to production. See Deploy only your rows.

  • Choose what a pull compares. Pull My Changes asks where to read rows from (the current connection, another connection, a branch, or the workspace on disk) and what to compare them with (this branch without your changes, another branch, or a database such as production). Comparing against production is how you capture a change somebody made straight into a shared environment; comparing against main is how you refresh a changeset after main has moved on.

  • One table description, shared between components. A data template's table and column description is written once to definitions/<category>/<template>.<hash>.json, keyed by a hash of its content, and each document points at it rather than repeating it. This is the default for documents, so a template that generates hundreds of components produces hundreds of small files instead of hundreds of copies of the same description. Definition="inline" puts it back inside each document where you would rather they stood alone. The commit view makes sure a definition goes in with the documents that point at it. See Sharing one definition.

  • Build a deployable package from source control. datastar --command-name build reads a deployment file, fetches each item as a blob at the revision it is pinned at, inflates any data document or changeset to SQL, and writes scripts, a manifest and, if you ask, a zip or NuGet package. Nothing is checked out and no workspace is needed, and because the documents are inflated at build time the package needs no templates and no database when it lands. That lets a pipeline build once and decide afterwards which environment to deploy to. A release that bundles several work items has their changesets for a component combined into one, as the client does, so the package holds one file per component. See build.

  • DataStar.Tools installs as a .NET tool. dotnet tool install --global DataStar.Tools installs it from nuget.org and puts a datastar command on the path, per platform, alongside the existing zip and Linux tarball. The packages can also be pushed to your own NuGet feed. See Install it from your own NuGet feed.

  • Three more CLI commands. inflate turns data documents into SQL with no database and no licence; definitions lists, prunes, shares or inlines shared definitions; merge is a git merge driver that merges documents and changesets by row instead of by line. None of the three needs a licence key. See the CLI reference.

  • See both sides of a deployment item. The Deployment view gains Open Document (JSON) beside Open Script, so you can read the rows an item carries as well as the SQL it will run, and a Kind column marking each row as a changeset (CS), a data document deployed whole (SS), or a script a template triggered (TR). Add Components... gains a DataChangesets method that adds every changeset a work item keeps. Add from Basket takes a changeset-deploying component's changeset for the work item, or its whole document when there is none.

  • Run a changeset's rollback. Run Rollback SQL runs the SQL that reverses a changeset against the open connection, committing or rolling back as you choose, and defaulting to rolling back so it can be watched against a real target safely.

  • Deploy case-only changes on SQL Server. A data script compares values under the database's collation, so on a case-insensitive database a change of case alone was never deployed. ExactComparison="true" on a data template compares them exactly, so the change is deployed, and a key renamed only in case is renamed in place. It is off by default. See SQL Server: case-only changes.

  • A changeset folder in workspace settings. Changeset Location on the Paths & Filters tab says where changesets are kept; it defaults to changesets, beside the component folder.

  • Deploy a branch at one commit (Branch mode). A deployment file is now Pinned (each item as it was at the commit it is pinned to, as before) or Branch (every item as it is on the branch at one commit: HEAD when deploying from the client, the build revision when build packages it). The workspace's Deployment Mode setting picks the mode new files start in, and the toolbar switches a file between the two. In Branch mode a header above the grid shows the one commit every item is at, who made it and when, and offers Move to HEAD when the branch has moved on. See Pinned and Branch mode.

  • Deployment files as JSON. A new deployment file, or one saved fresh to a task, can be written as deployment.json instead of deployment.xml; the workspace's Deployment File Format setting chooses. A file that is opened is saved back in its own format, Save As with the other extension converts it, and build and the client read either.

  • Let an agent do a task end to end. Tell an agent which task you are working on and what to change, and four new MCP tools let it go from there to pushed changes: work_on_task puts the workspace on the task's branch, creating one when there is none; pull_task_rows takes the task's rows of a changeset component, as Pull My Changes does, against this branch or a database such as production; commit_task_changes commits with the shared definitions and changeset partners the files need; and push_task_changes pushes and settles the commits with the task tracker. Whatever is yours to decide, such as uncommitted changes, starting a changeset again, or a remote that has moved on, is refused with the question to ask, and a failure says what it left behind and why. An agent can no longer extract a changeset component whole. get_workspace_info now reports the branch, its task and the categories that deploy changesets, and extract_components returns the paths it wrote. See Working on a task.

  • Choose what a commit's task is, and link Git commits to work items. Task on Commits in workspace settings is Optional, Required or Off, replacing Require Task ID on Commits (a workspace with it ticked reads as Required). Link Commits to Work Items links each pushed Git commit that names a task to its Azure Boards work item, shown as Fixed in Commit, when the remote is Azure Repos in the same organisation. It is off by default, so nothing changes until you turn it on; Jira, or any other remote, never links; TFVC check-ins associate their work item as before, and a workspace with no task tracker records the branch's task as it always did. A version of DataStar older than 3.1 that saves the workspace settings drops both settings. Every way of pushing now handles a commit's task the same way, and the Release Workflow's own commits carry its work item. The Git commit dialog offers the task field with any task tracker, Jira included, not only Azure Boards, and under Required it shows the field even with no tracker. See Commits and Branches.

Improvements​

Changes to what 3.0 already did. Everything that is new in 3.1 is described above as it now works.

  • Workspace Settings: the General tab fits without scrolling. Its settings are grouped into Commits and Branches, Scripts, Deployment Files and Deployment History Tables, in two columns, each with its full explanation, and the window opens large enough to show them all, or as large as the screen allows. See Tab 1: General.
  • Database Snapshot says why: hover over an item's status to see why it could not be compared (not in version control at its pinned version, no DataStar header, a template that cannot be found). One such item no longer stops the whole snapshot, and anything that would stop the deployment is listed in one dialog that names each item. See Previewing before you run.
  • Compare a deployment item with more than the snapshot. A row's right-click menu gathers its compares under Compare With…, and adds the current connection, a database you pick, a branch and the remote to Latest, Workspace and DB Snapshot. A data document compared with a database, or with the last Database Snapshot, now reads as JSON: the document beside its component captured from the database, rather than the SQL each would deploy as. A changeset compares as its changeset file beside the same changes as the database holds them, both in the changeset file's JSON, and a script as SQL. See Per-row preview.
  • MCP: preview_deployment_changes reads a work item's deployment file from the work item's own branch, so an agent can answer "what would DAT-21 do to PRD?" without the branch being checked out. Every item it cannot compare says why, and scripts and diffs are capped so a large deployment fits an agent's context (detail='full' returns everything). generate_reversal_scripts works from each item at the version it deploys at rather than the workspace files, and manage_deployment reads and describes a work item's file from its branch too. extract_components into a draft reports a failed extraction as failed. The server now tells a connecting agent how to answer questions about a work item's deployment. See the MCP tool catalog.
  • The recent deployments menu lists only the open workspace's deployments, each by its path in the workspace. A folder pattern that names every file deployment.json no longer lists them all alike, and another workspace's deployment is no longer opened into this one.
  • Welcome to DataStar, started while another DataStar holds the workspace, offers Close It beside Bring to Front. The running DataStar closes as its own Exit would, asking first about unsaved changes, and the workspace it held can then be opened.
  • Adding a Git remote to an open workspace enables Pull, Push, Fetch, Prune, Outgoing and Incoming without restarting.
  • Opening a deployment file whose items' versions are repaired while it is checked marks the file as changed, so the repair can be saved or discarded rather than silently redone on every open.
  • Scratch folders written by the read-only viewers and comparisons are swept at start-up rather than accumulating.
  • Oracle: a data script whose first update column is computed or does not trigger an update no longer starts its column list with a comma (ORA-00936).
  • The About window shows the build's commit date rather than the time it was compiled.

Notes for upgrading​

  • Data templates without a Version now script as version 2 on SQL Server. Version used to default to 1 (deletes inside the MERGE, a parent's delete cascading to every joined child unless told not to). It now defaults to 2: deletes identified from the loaded rows and run at the end of the script, cascading only to tables that set DeleteCascade="true". The change takes effect the next time a component is extracted. If you rely on the older script, set Version="1" on those templates before upgrading. Oracle scripts are the same either way. See SQL Server: Version 2 templates.
  • Components without a SortOrder are extracted in key order. A data component whose template gives no SortOrder used to be extracted in whatever order the database returned, which could change from one extract to the next. It is now ordered by its keys, so the first extract after upgrading re-orders its rows once. The rows themselves are unchanged.
  • build refuses an output directory that is not empty. Everything in the output directory goes into the package, so files left by an earlier build would ship in the next. Give an empty folder, or add --clean to empty it first. An Azure DevOps $(Build.ArtifactStagingDirectory) is empty at the start of every run. A pipeline that used to write metadata.json or download the deployment file into the output folder before packaging no longer needs to: build puts both in the package itself. Anything else goes in with --include.
  • Save DB Snapshot has been removed. It wrote the last Database Snapshot to a .sql file that DataStar never read back, which left out what the deployment would create and could not be run as a rollback. To put a database back, use Export Reversal Script before deploying; to see what differs, use Compare With… on a row. See Exporting a reversal script ahead of time.
  • OutputFormat, DeployMode and Definition all default to today's behaviour, so a template that sets none of them still writes .sql and deploys a snapshot.
  • Changing a template to OutputFormat="json" changes the file its components are committed as. Extract them again so the .json is written and the .sql removed, and commit both halves together with the definitions folder. Deployment files that pin the old .sql at a commit keep building. See Migrating an existing .sql template.
  • The manage_basket MCP tool has been removed. An agent no longer stages components in the basket: it builds the task's deployment file with manage_deployment (action='build', with the components) and commits it with commit_task_changes. A saved basket.xml attachment can still be read with manage_task_attachment. Agent prompts or scripts that call manage_basket need updating. See Working on a task.
  • Everyone on the workspace needs 3.1 before documents or changesets are committed. An older DataStar cannot read a shared-definition document or a changeset, and says so rather than deploying it as something else.
  • The DataStar.Tools NuGet package is now a .NET tool. Up to 3.0 the DataStar.Tools package held DataStar.Tools.exe under content. From 3.1 it installs with dotnet tool install --global DataStar.Tools and holds no program itself: each platform package (DataStar.Tools.win-x64, DataStar.Tools.linux-x64, ...) keeps it under tools/net10.0/<platform>, built for the .NET 10 runtime. Anything that unpacked the old package and ran content/DataStar.Tools.exe should install the tool instead, or use the self-contained zip, DataStar.Tools.<version>.zip, which needs no runtime. See Installing DataStar.Tools.
  • Register the merge driver yourself. DataStar ships datastar --command-name merge but does not write your git config or .gitattributes; until it is registered, git merges documents by line, which conflicts more often than it needs to. See merge.
  • Packaging shared-definition documents without build. The release command still inflates documents at deploy time, but it finds a shared definition in a definitions folder above the document. A package laid out by GitSources.Tools or the Azure Get Sources task has none, so either switch that stage to build or copy the workspace's definitions folder into the package root.
  • Data documents and shared definitions extracted with an earlier 3.1 preview should be extracted again: what a document records about its template, and what a definition's identity covers, changed during development, and an older document carries no script surface, so it inflates only where the template can be found and reports a template change when there has been none.
Last updated on