T-SQL is where the actual behaviour of most SQL Server systems lives — the stored procedures, views, functions and triggers that nobody documented and everyone is slightly afraid of.

If yours is slow, broken, unreadable, or nobody can work out what it does any more, we can help. ☎

Not sure this is what you need? Start with SQL Server support and consultancy or the SQL Server overview.

Tidy

Is your T-SQL a mess? Inconsistent naming, copy-pasted blocks, dead procedures nobody dares delete, no error handling in half of it, and objects originally created by a wizard and edited by hand ever since.

We standardise it so it’s clear and logical, and so the next person to open it — us or anyone else — can follow it.

If you just want it formatted, SQL PR will beautify it in seconds and costs almost nothing. Use that. What it won’t do is tell you which of those four hundred procedures are still called, which two do the same job slightly differently, or why the one that matters takes ninety seconds. That’s the part we do.

Analysis and testing

Need to get to the bottom of what the database is actually doing?

We work through the code, comment it, and report back on every object: what runs when, what calls what, which procedures are no longer reachable, where the transactions aren’t committed, and where the risks are.

That’s usually the first job on a system somebody else built, and it’s also what makes everything afterwards quotable.

Document

[IMG-1] — A page of genuine documentation output: object inventory or dependency map, redacted. The deliverable is a document, so show the document.
Alt: SQL Server database object documentation report

We produce a full written record of every object in the database — tables, views, stored procedures, functions, triggers, jobs — and how they depend on each other.

This matters most when the person who built it has retired, left, or was never a developer. Once it’s written down you’re no longer relying on one person’s memory, and any competent developer can pick it up. Plenty of clients commission this on its own, with no other work attached.

Code tuning

Is bad T-SQL causing slowdowns or errors? The usual suspects:

  • Cursors and row-by-row processing where a set-based statement would do the same work in a fraction of the time
  • Scalar functions called per row, quietly serialising everything around them
  • Non-SARGable predicates — functions wrapped round indexed columns, so the index never gets used
  • Implicit conversions, usually a varchar parameter meeting an nvarchar column
  • Parameter sniffing, where the same procedure is fast for one customer and unusable for another
  • SELECT * in production code, pulling columns nobody wants across the network
  • NOLOCK sprinkled everywhere as a performance fix, quietly returning wrong results
  • Missing SET NOCOUNT ON, and transactions that stay open longer than they need to
  • Dynamic SQL built by concatenation — a performance problem and an injection risk in the same line

SQL Server performance tuning

Code that won’t survive an upgrade

The other reason people ring us about T-SQL: the upgrade broke it.

Old-style outer joins, deprecated data types, sp_ procedures Microsoft has removed, SET ROWCOUNT used for updates and deletes, and compatibility-level behaviour that changes execution plans without changing a line of code.

If you’re moving off SQL Server 2016 or earlier, the upgrade itself is rarely the hard part — the T-SQL on top of it is → SQL Server migration and upgrades

SQL Server Support & Consultancy

Ongoing support, fixes and development.

Find out more...
SQL Server Performance Tuning

The wider performance picture, not just the code.

Find out more...
SQL Server Health Check

Independent review of the whole environment.

Find out more...

Got T-SQL nobody understands?

Send us the database and we'll tell you what's in it, what's broken, what's slow and what it would take to put right.

Send us the details → SQL Server Health Check →