Conections To Ignore export and import

cobyst

Hi,

I am evaluating SQL Prompt 3.5.

I want to export my "Connections To Ignore" list so other developers will be able to import the list and can get it automatically.

Can I do that?

Bart Read

The answer is kind of (maybe) yes, but it's not something we really support, and to do it you have to share you're entire cache, not just the servers and databases you want to ignore. I've pulled the following comments and instructions related to this issue from our bug tracking system:

You can specify the location in which cache files will be saved in the registry. If it's not already there, which it probably won't be, add a key called:

\\HKCU\Software\Red Gate\SQL Prompt 3

Under this key create a value called "Cache Folder" and set it to the absolute path defining the location where you wish the cache files to be stored. In this case you'd want it to a UNC path to a network share directory that will be used by all users of SQL Prompt. Obviously they're all going to need read/write access to that directory.

They should then be able to share files in that directory HOWEVER

1. We've never tried this using a shared path for multiple machines and that's not really what it's designed to do so it may or may not work.
2. On any given machine mutually exclusive access to the cache files between multiple editor instances running SQL Prompt (e.g. SSMS, QA and VS 2005 all running at the same time) is guaranteed by an operating system mutex. Clearly this will not guarantee mutually exclusive access for multiple machines accessing a network shared directory. The cache should be fault tolerant enough to deal with any problems this might cause relatively gracefully, by which I mean I'm pretty sure it wouldn't crash or deadlock or anything horrible that like, but you may find that recaching operations occur slightly more frequently than you might expect or something along those lines.

In short, I think it's probably worth a try, I think there's a good chance it might work, but we don't make any guarantees about it, it's not a solution we officially support (it's actually something I added to help our testers to avoid them trashing their cache whenever they ran automated tests etc), the usual disclaimers apply, blah, blah, at your own risk, etc, etc.

You can also configure locations for the other settings in SQL Prompt using other values under this key:

"Options Folder" - specifies the location where SQL Prompt stores options and the log files, although not, I believe, any options that are UI specific.

"Snippets Folder" - specifies the location where SQL Prompt will store its snippets file.

"Completion Config Folder" - specifies the location where SQL Prompt will store the configuration file that defines the order of objects in its completion lists (I wouldn't recommend playing with this, but if you do and it all goes horribly wrong just delete the file and SQL Prompt will recreate it.)

This means that you can share other things, not just the cache files, but again the usual disclaimers... at your own risk... blah, blah, etc, etc.

So as it says, the best thing to do is give it a try and see if it works for you or not.

Hope that helps.


Thanks,
Bart

cobyst

Thanks.
I'm not sure if that's a scalable solution for us, but I might try it.

The workaround of setting it up manually might be good enough.

Bart Read

If you're dealing with quite a few developers/DBAs that could well be true. I can see it working OK for half a dozen people, but 20, 100? I'm not so sure it would be such a great plan. I suspect the "SQL Prompt Meta Data Cache.cache" file would end up being modified so often that it might cause problems.

The other thing you might want to consider is setting up the list somewhere and merging it into the separate "SQL Prompt Meta Data Cache.cache" files. This file, which normally lives in "C:\Documents and Settings\{username}\Local Settings\Application Data\Red Gate\SQL Prompt 3" is actually just an XML file. If you set up a few servers and databases to ignore you'll see that they're populated within the <BlacklistedDatabases> element. The structure below this element is fairly simple so writing some sort of script to periodically merge the list with peoples' local files wouldn't be that tricky.

Hope that helps.


Thanks,
Bart