FR: Common snippets

Then snippets are restricted to their respective DB type which is good for those that require something special only that DB type provides. But there could be a group for Common type snippets for those that are, well, common.

Thank you for your suggestion. Unfortunately it might be technically difficult to implement database-agnostic snippets because of the current SQL Assistant architecture. Snippet processing is tightly coupled with the database type-aware functions that's why they are kind of placed into different compartments by type. The UI is a kind of reflection of that. I don't know how difficult it would be to change the UI to support a shared compartment automatically loaded by functions for each database type.

Hmm, I see. I always assumed that you have some sort of database abstraction layer that sits between the code/snippets/db queries/whatsoever and the connection to an actual database that translates/interprets and allows the usage of the same macros ($OBJECT(...)$, $COLUMNS(...)$, $ARGS(...)$ and $$...$$) for different types of connections, since I don't see any difference in available macros for them. But that plays no role here.

Regarding the UI, I don't see anything DB type related there for the snippets, except that I have put the snippets into one of the groups, eg. T-SQL Snippets, MySQL Snippets, etc. and that it has SQL Dialect. But that setting does not enforce the dialect itself, it assigns the set of snippets to the type of the DB connection instead. From my point of view the difference between what I suggest and what you currently do is diminutive. It is something you already do but is too restrictive. Let me try to explain it.

When I establish a connection to a database SA selects the available set of snippets based on the type of the DB the connection is established to, that is, when the type of the DB I'm connected to is eg. SQL Server, then the editor allows me to choose snippets from T-SQL Snippets. Now I've got absolutely no idea how you internally process an $OBJECT$ macro but I don't even think it matters. I guess you're executing the snippets as they happen and don't prepare the queries when the connection is made but even if you do so it still does not matter.

You see, there's nothing to prevent me from creating snippets with exactly the same content for several different DB type (as long as it makes sense in that one, of course, in which case common sense might kick in). Actually, I'm already forced to do that because there are things I regularly use regardless of what DB type I'm connected to. When I trigger the snippet, it is going to be processed by SA anyway and it is going to be processed based on the type of the DB the connection is established to.

The thing I'm asking for looks simple (though I know it might not be). Besides having sets of snippets that could be set for registered targets and are assigned to a specific SQL Dialect you could introduce a new 'SQL Dialect' named Common (which could even be set on its own for registered targets) and instead of only enabling the set of snippets assigned to the registered target, you could enable the UNION of the assigned AND Common sets.

If I put something in the Common set that doesn't belong there (it's DB specific) it's my funeral. But that could just as easily happen with other sets as well. I've already misplaced snippets countless times. Having a Common set could reduce mistakes and what's more important the maintenance costs of the same snippets in different sets