I know both of these are long shots, but with my dependence on SSMS shrinking it would be nice to have a profiler and debugger toolset in SQL Assistant. Is that at all possible?

Mon Nov 14, 2016 10:01 am

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

This is a kind of question that I'm afraid no one can answer in this forum. We know it's technically possible, it's available in SSMS. The SQL Profiler isn't part of SSMS though, it's a separate utility, and building on top of SQL profiler API to the best of my knowledge is certainly doable, years ago we develop a performance statistics automated collection add-on for DB Audit that works with SQL Server and built on top of the API.

My imagination is telling me that developing a full fledged multi-database debugger and/or profiler would require a hell of a job. We are supporting 13 different database server types and 6 different database interfaces. Even if only half of them support debugging and profiling APIs, that would be still huge.

Last edited by SysOp on Mon Nov 14, 2016 11:02 am; edited 1 time in total

Mon Nov 14, 2016 10:32 am

Mindflux

Joined: 25 May 2013Posts: 641Country: United States

I totally understand. I do not know what it entails to make a debugger for SQL.

I thought (maybe wrong) that the SQL debuggers were 'simple' in nature (not to program). Meaning it lets you step through each line and can allow you to watch the declared variables and step into and out of functions or procedures.. set break points and stop the execution if needed. I guess that's just about like any other debugger though...

Mon Nov 14, 2016 10:51 am

gemisigo

Joined: 11 Mar 2010Posts: 1438

Mindflux wrote:

I thought (maybe wrong) that the SQL debuggers were 'simple' in nature (not to program). Meaning it lets you step through each line and can allow you to watch the declared variables and step into and out of functions or procedures.. set break points and stop the execution if needed. I guess that's just about like any other debugger though...

Most probably not the case. You see, when debugging a program, you reset the environment by simply reinitializing the state machine (reinit variables and memory areas, rewrite files with their original contents, put IP to the start and the rest of the whole shebang that happens in the background). It's all about you being the only one that uses it, no multiple programmers trying to debug the same app in the same environment at the same time. With databases this is a bit more complicated, you've got to handle transactions to preserve the state machine and there're many things that can ruin your environment without you even knowing about it (other connections running statements, background jobs, etc.). Awful lot of things to take care of. Handling of variable, for example, MySQL has local variables for stored programs and session variables that retain their values for the connection, in SQL Server you can only query them during execution. And this is only one from a whole bunch of other stuff that feel their life goal to make your life a nightmare.

It's certainly doable, and I'd like to see it in here, very much indeed. But I'm also sure it's incredibly complex. Still, I support the idea.