 |
SoftTree Technologies
Technical Support Forums
|
|
Author |
Message |
gemisigo
Joined: 11 Mar 2010 Posts: 2165
|
|
FR: Collecting multiple prompts to a single dialog |
|
Having multiple prompt dialogs in a single snippet helps making them extremely configurable but also has the somewhat adverse effect of "not-seeing-the-whole-picture" during the execution of said snippet. Also, making a mistake when traversing the chain of prompts will lead to aborting and restarting the entire snippet (possibly making another mistake at another step). Would you consider collecting all the prompts in the snippets at the start of executing it into a single dialog instead of showing each individually, one after the other?
|
|
Thu Feb 20, 2025 6:24 am |
|
 |
SysOp
Site Admin
Joined: 26 Nov 2006 Posts: 7948
|
|
|
|
It's already trying to compile identical macros as not to prompt multiple times, but when they are different by design, how can it show them together? Is there an example demonstrating the same prompt showing multiple times?
|
|
Thu Feb 20, 2025 9:25 am |
|
 |
gemisigo
Joined: 11 Mar 2010 Posts: 2165
|
|
|
|
I think you misunderstood me. The same prompt showing multiple times is not an issue. That does not happen. I'll try to clarify.
Besides being a developer, I am also a proverbial "accidental dba" (because we have no other people to do that). Over the years I've accumulated a large number of snippets to make my job easier. There are tons of snippets to list databases or other objects (tables, views, procedures, functions, triggers, indexes, you name it) to check for their properties that could cause issues or help optimize them. So, I have monstrosities like these below at the start of many snippets:
 |
 |
-- list databases and their properties
$PROMPT(@name_mask,Name mask?,%%,List databases)$
$PROMPT(@target_maxdop,Target maxDOP?,0,List databases)$
$PROMPT(@do_include_system,Include system databases?,,List databases,0 1,NO YES)$
$PROMPT(@name_not_mask,Name NOT mask?,,List databases)$
$PROMPT(@owner_mask,Owner name mask?,%%,List databases)$
$PROMPT(@owner_not_mask,Owner name NOT mask?,,List databases)$
$PROMPT(@collation_mask,Collation mask?,%%,List databases)$
$PROMPT(@collation_not_mask,Collation NOT mask?,,List databases)$
$PROMPT(@snapshot_mask,Snapshot of mask?,%%,List databases)$
...
|
or
 |
 |
-- list procedures
$PROMPT(@content_mask,Content filter (use %\, _ and [_] wisely :) ?,%%,List Stored Procedures)$
$PROMPT(@schema_mask,Schema name filter (use %\, _ and [_] wisely :) ?,%%,List Stored Procedures)$
$PROMPT(@object_mask,Object name filter (use %\, _ and [_] wisely :) ?,%%,List Stored Procedures)$
$PROMPT(@excl_content_mask,Exclude content filter (use %\, _ and [_] wisely :) ?,,List Stored Procedures)$
$PROMPT(@excl_schema_mask,Exclude schema name filter (use %\, _ and [_] wisely :) ?,,List Stored Procedures)$
$PROMPT(@excl_object_mask,Exclude object name filter (use %\, _ and [_] wisely :) ?,,List Stored Procedures)$
$PROMPT(@code_length,Code length criterion (use <combinations>= 2,List Stored Procedures)$
...
|
I have snippets like these for listing things, but also for creating things, checking stuff, etc., so I'm using prompts for both development and dba stuff. I'm not sure if other users of SA do the same, but if they don't, then those prompts are the most underused feature in SA. They (almost) remove the work from the workflow.
Now, these prompts use defaults that work most of the time so I also developed the habit of just leaning on the Enter and expecting the miracle to happen. Which it does. Usually. But that habit is more of a reflex than a habit. So when I do have to use those prompts to filter on something, I'm regularly way past the one I want to change, so I have to start from the beginning (and hope that I don't do that again).
Currently, each of those snippets has its own dialog. Those dialogs consist of a title, a text (description), and an input (either a short text input field or a drop-down). If those prompts were collected onto a single dialog window instead, where one could check everything in a blink of an eye and have a single OK button to say 'aye', the number of those accidental mistakes could be significantly lower and the whole process could be made faster. As for the method of "collecting", I guess even simply dropping them under each other would work pretty well.
|
|
Mon Feb 24, 2025 5:24 am |
|
 |
SysOp
Site Admin
Joined: 26 Nov 2006 Posts: 7948
|
|
|
|
Thank you very much, I understand that now. I'm sorry I had hard time imagining a macro complexity of that scale :-)
I think no one here expected this sort of a use case for the PROMPT macros. Maybe because of our developer's mindset... much easier to imagine a custom dialog developed using SQL Assistant's provided Plugin Development IDE which can be used to collect multiple inputs. It requires a little bigger effort, but offers much more flexibility.
I will enter an enhancement request to combine multiple PROMPT macros in the same dialog.
Here is how one can create custom UI dialog supporting many different types of programmatic controls.

|
|
Mon Feb 24, 2025 9:59 am |
|
 |
gemisigo
Joined: 11 Mar 2010 Posts: 2165
|
|
|
|
That sounds interesting. But can I replace the $PROMPT(...)$ macro with such a custom dialog? Or would that approach require moving the entire logic from the snippet to a custom plugin? Can the dialog be built dynamically or would it require "facelifting" every time I add/remove the prompt (or its plugin equivalent) to the logic? I also guess each snippet converted to a plugin would require its own purpose-built custom dialog, so converting them to plugins would be quite an enterprise. Not all of them have prompts (or at least many prompts) but it would feel incomplete to move some to plugins and leave the rest as snippets. I have these in the hundreds.
The plugin developer IDE is not SQL (obviously) and I'm no longer a programmer. The last time I touched any of those languages the IDE popped up was... er... Well, quite a bit closer to 25 years than 20. I'm not sure I'm up to the task to learn or re-learn them anymore. I'm too old for this :)
|
|
Mon Feb 24, 2025 11:00 am |
|
 |
SysOp
Site Admin
Joined: 26 Nov 2006 Posts: 7948
|
|
|
|
It would require moving the logic, or... copying it to a SQL file, which the dialog can read in run time, replace variable placeholders, and then execute it. Another benefit , the dialog can support conditional logic for input values, multi-step execution, execute multiple scripts, etc.... comparably that requires a bigger effort as a price to pay for having more options.
|
|
Mon Feb 24, 2025 4:42 pm |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|