XS Tool Suite might seem overwhelmingly large at first - but it doesn't have to be! We like to focus on three main areas where we've consistently received praise:
Bob starts his day by starting XS Tool Suite. He picks up where he left off yesterday: he pinned two windows that re-open - a stored procedure and a SQL script. He had previously established a few dozen "global connections" - one of them called "MyApp-Dev", another called "MyApp-Staging". He makes a few changes to his stored procedure in development and wants to promote it to the staging environment. He hits F5 to commit his Dev changes, then invokes the "Execute In" feature. He's prompted with a list of suggested connections, with "MyApp-Staging" appearing at the top of the list, since he's used that connection several times before, from Dev.
Suddenly Bob realizes he made a mistake and wishes he could go back to an earlier committed version of the procedure that he was working on yesterday in development. (Does he check in every single change he makes in development, as he works? No. YMMV.) He uses the context menu to "Show History" on the procedure - and gets a list of every version of the object's text, in Dev. He double-clicks on the version he wants, and a new window opens with its text. He hits F5 to commit it in the database.
He starts working in the procedure and sees the name of a user-defined function (UDF) that he wants to examine. Rather than go hunt for it, he double-clicks on the UDF name, selecting the text of the name. He then presses F2 (Find Object) and the UDF instantly opens in a new window. Bob makes a change in the UDF and the window with the UDF text shifts to become the first open window: Bob has elected to order windows based on modified date (and auto-closing the oldest unchanged windows), keeping active work grouped together, thus reducing the inevitable "hunting" he was accustomed to with other tools.
Now Bob wonders about an UPDATE he ran against a table that he did last week. He selects "Recorded History" and gets a grid-based list of every executed statement he's ever invoked. He applies a search filter and finds a subset of work that contains his statement of interest. He double-clicks the row and its related text opens in a new window.
It's time for Bob to do some more SQL coding. He'd like to write an INSERT statement, based off an existing table. He types "inssel" and hits Tab twice. He's prompted for a table name, which he provides and hits OK. Suddenly the text "inssel" disappears - and is replaced with an INSERT statement, listing columns from the source table, followed by a SELECT statement - again listing columns from the source table. He used eight keystrokes to save potentially a couple hundred! He smiles, knowing he can do this with many other scenarios. All of them are leveraging the XS Tool Suite code generation engine. He thinks of another "intelligent snippet" he could write himself, using the template editor.
Next, he wants to compare data differences between some data in Dev and Staging. It's not as simple as comparing table contents directly (otherwise he might switch to the "Data Compare" window) - what he really wants to do is compare the difference between the result sets of a query run against Dev and Staging. He can easily do this: he writes the query, hits the Ctrl-E short-cut to execute the individual query (out of possibly many queries in his current editor window), then does "Execute In" again to run it against the second database. With a result set visible, he opens the context menu on it and invokes "Compare Result Grids". The selection window that appears has found the two "comparable" result sets, he picks the desired compare keys, and he's next presented a color-coded set of differences in the two result sets.
He'd like to script some rows from one of the result sets into INSERT statements. He multi-selects rows in the result grid, invokes the grid context menu, picks Templates -> Inline T-SQL and DML -> INSERT with values (Results). A parameter window appears, asking for which subset of columns he wants to include, among other parameters that help give more options for the generated INSERT's. Bob realizes that he'd like to share the result set with a colleague, with some commentary, in an e-mail. He invokes the context menu on the grid and picks To Clipboard -> As HTML. He then pastes into Outlook and gets a nicely formatted table for the rows (as with the template, he could have done a subset of rows or columns).
Bob being very popular among users and his development team gets asked about an error message showing up in an application that seems to be originating from a known SQL Server database, but an unknown object. Bob switches to this database quickly using a hot-key combination he previously established for that database's global connection alias. He then invokes the "Build Search RegEx" tool window and types in some of the error message that someone reads off to him. (He's unsure about spacing, but this tool builds a regular expression that's insensitive to white-space.) When he clicks OK, in a few seconds his object list has been filtered to only show objects that contain the text, including one stored procedure that he can now investigate for what might have led to the error. Of note, Bob could use search terms such as NEAR, OR, AND, NOT, REGEX, and WW (whole-word) in a way that's intuitive for content searches. Also of note: he can just as easily do the same type of content searching through data as well!
Later, Bob creates a view that's a candidate to be materialized for performance reasons. Similar to how he could invoke templates against result sets, Bob picks the view and uses a different template to create a MERGE from the view. He's given the ability to persist the natural key columns that will be used, and could re-generate the MERGE easily if his view changes. The principle of using repeatable templates helps share knowledge among a team, encourage consistency, and can be automated using the SHCommand command-line tool.
Bob's also interested in running some of his favorite DMV monitoring queries. He's added them to the Monitoring tool in XS Tool Suite and can watch how values change, highlighted with color coding. In fact, he can record samples over time and feed this into a data warehouse that supports "querying your queries." Your performance metadata doesn't need to be hidden behind a wall.
This is just a glimpse of what XS Tool Suite can do for you. We encourage you to try it out and drop us a line if you have questions. Note that some features require that you install server components. These include a back-end database, a web site hosted in IIS, and a Windows service. One of our installation options lets you install all components on a single machine, which is great for getting familiar with the product.
Drag Column Names to Editor Window
It sounds simple - and it is: you can drag result set column names into an editor window.
Want to see all spotlight features? Click here
The XS Tool Suite is based on a freemium model. Some features of the product do require a key - you won't be asked for it until you invoke one of these. You can easily obtain a key by registering here, on xskrape.com. The freemium model means your need to pay is proportional to how much you actually love and use the product! Also keep in mind: new users get enough of a discount that you can use all premium features for 30 days, for free. Keys you manage for your account can be used on any machine in your organization - you're responsible for how you want to deploy these keys.
Keep in mind: these per machine, per month credit charges apply to most products we distribute, so if you're paying for one, you get all of them that use this payment model.
For XS Tool Suite (Desktop), you're charged account credits per machine, per month, only when you use premium features, including: