Previously on Mac I use mysql operation studio and I click on database and click restore then browse to my bak file, but now they change to azure data studio and when I repeat the same steps I got this error:
"You must enable preview features in order to use restore"
but I cannot figure out hot to enable that. I have googled and tried few things even open my azure, microsoft account on website but I do not see that option.
Can some one help please !
Go to Azure Data Studios > Settings
Edit settings by clicking on
"new settings editor"
Search for "preview"
Scroll to the bottom and
check "Enable unreleased preview features"
Adding this as an answer as I don't have enough rep to comment. This is in response to the question in the comment for the answer to the OP (If that's not confusing enough!)
This only applies when your sql database is hosted on a Mac/Linux/Docker Container. We don't have any Windows servers in our estate for me to test this on to see if the location of the .bak files is any different.
When you click on the "..." button, it browses to /var/opt/mssql/data on the machine (or docker container) the database is hosted on. This is not an issue if you are backing up & restoring databases on the same host, however, if you're migrating to a new server or just creating a dev/UAT/staging environment, it becomes a problem because you don't have access to var/opt/mssql/data.
This is a bit of a sledgehammer to crack a nut type solution but as I'm working with 2 dev boxes, it doesn't make a lot of difference to me.
To make this easier to understand I'll call the server that hosts the database you have backed up ProdServ & the server you are restoring to DevServ.
On DevServ, at a terminal prompt, navigate to /var/opt and make a note of the current permissions on the mssql directory (mine were drwxrwx---).
$ cd /var/opt
$ ls -la
Google the octal value for your permissions (in my instance, it's 770)
Change the permissions of the data directory to rwxrwxrwx.
$ chmod -R 777 /var/opt/mssql/data
(You will also need to do this on ProdServ if that is also a Unix-based o/s)
Copy the .bak files from ProdServ to DevServ via a method suitable to the environment you're working in.
Windows --> Linux I'd use WinSCP
For Mac to Docker, docker cp <fileToCopy> <container>:<destinationPath> works perfectly fine.
Once the files have been copied over, they will magically appear when you click the "..." button in azure data studio again. Make sure you change the directory permissions back to their original value via the same command. So in my instance, simply
$ chmod -R 770 /var/opt/mssql/data
As an extra note, if you're used to working in MSSMS, the wizard there allows you to create a database from a .bak file, from what I can see, Azure Data Studio does not. You have to create the database first (CREATE DATABASE <databasename>) in a query window, then restore the .bak file to it.
simple add this to your setting file:
"workbench.enablePreviewFeatures": true
You can click on View at the top menu next to Window.
Then select the first option Command Palette
Then in the command textbox type Restore and select Restore
Then the restore window comes up.
Related
I am having an issue with Azure Storage Emulator. I tried to re-initialise the database and got the error below.
This was after installing Visual Studio 2019 Preview but this may just be a co-incidence. I tried for an hour or so to get it running and then gave up and just reset my machine with the "keep my files" option, re-installed Visual Studio 2017 and the Azure Tools but still see the same problem.
I know a reset sounds a bit drastic but VS 2019 broke my Azure Functions in VS2017, they would not launch so I wanted a clean install.
If I manually create the DB with sqllocaldb create (version 13.1.4001.0), the DB gets created fine but the init still fails with the same message.
Any ideas?
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage
Emulator>AzureStorageEmulator.exe init
Windows Azure Storage Emulator 5.7.0.0 command line tool
Found SQL Instance (localdb)\MSSQLLocalDB.
Creating database AzureStorageEmulatorDb57 on SQL instance '(localdb)\MSSQLLocalDB'.
Cannot create database 'AzureStorageEmulatorDb57' : The database 'AzureStorageEmulatorDb57' does not exist. Supply a valid database
name. To see available databases, use sys.databases..
One or more initialization actions have failed. Resolve these errors before attempting to run the storage emulator again.
Error: Cannot create database 'AzureStorageEmulatorDb57' : The database 'AzureStorageEmulatorDb57' does not exist. Supply a valid
database name. To see available databases, use sys.databases..
After resetting my machine (and keeping files), I ran into this issue. For me, I was unable to run an Azure function in Visual Studio 2019 due to an error around being unable to start the emulator.
It looks like I had the same permissions issues as (I presume) my new account after reset, did not have permission to touch the DB.
I resolved this by:
Deleting the Azure Storage Emulator DB file: %USERPROFILE%/AzureStorageEmulatorDb[number].mdf
Then running AzureStorageEmulator.exe start with admin rights
I was then able to run the Azure Function without issue.
Stop the Azure Emulator if it is running.
Open SSMS and connect to your (localdb) instance.
Manually create the "AzureStorageEmulatorDb57".
Open a command prompt as Administrator.
Run the "AzureStorageEmulator.exe init".
Run your VS project.
I was running into this same issue after installing LocalDb for SQL Server 2017. These steps helped me to resolve the problem I was facing:
Open a command line in C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator
Run AzureStorageEmulator.exe init /forceCreate
From checking my error logs (located at %USERPROFILE%\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB), I saw
2018-12-21 15:41:13.47 spid65 CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\Users{username}AzureStorageEmulatorDb59.mdf'.
This error lead me to the following post: https://dba.stackexchange.com/questions/191393/localdb-v14-creates-wrong-path-for-mdf-files
From reading answers there, I gathered that this is a bug in SQL Server 2017. Without having access to the patch, the solution that worked for me was granting Everyone access to modify C:\Users. This was only an issue on my development laptop, so I could afford to make that security change
or as commented by Andrii install CU13 HotFix for SQL Server 2017. After that AzureStorageEmulatorDb<xxx>.mdf will be created you your user directory as it should.
I had this problem and I don't know why an AzureStorageEmulatorDb57_log.ldf was still present in my %USERPROFILE% directory when I deleted my MSSQLLocalDB instance, but after dropping that file the problem went away.
I came across this issue where I had changed the userlogin to my machine. I have created the database from my previous useraccount. I have copied the database files to the new user account but it gave me this error. It seems to be a permission issue.
You need to find the saved location of the mdf and ldf file of this database. In my case it was stored in 'C:\Users\yourUserName'
Simply delete these files and run AzureStorageEmulator.exe init again and it will create the new mdf and ldf files for you.
After manually upgrading my MSSQL 2016 LocalDB to MSSQL 2019 following these instructions, I got the error mentioned as I was unaware that the Azure Storage Emulator uses LocalDB internally.
To fix it, I simply had to manually re-attach the database located in %UserProfile% with the following SQL command:
CREATE DATABASE [AzureStorageEmulatorDb510]
ON (FILENAME = 'C:\Users\<username>\AzureStorageEmulatorDb510.mdf'),
(FILENAME = 'C:\Users\<username>\AzureStorageEmulatorDb510_log.ldf')
FOR ATTACH;
Worked for me:
Delete any storage/sql database related to azure emulator
run this command on StorageEmulator path:
AzureStorageEmulator.exe init /server .
(Or your SQL instance, Mine was ".")
Check you had install Azure SDK with Visual Studio, if you did't you can add the feature
You can locate the mdf and ldf files in your userprofile directory. Just stop the emulator and copy those files to some other place and delete it from userprofile directory.
Then run the emulator again and it's going to create new mdf and ldf files.
Then stop the emulator and copy the old files back and restart the emulator. This way you won't loose any data.
I will help you with this. First of all create a sql server local db.
Then go to storage emulator folder
_-The Storage Emulator is installed by default to C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator.
Then run this AzureStorageEmulator.exe init /server
docs: AzureStorageEmulator.exe init /server localhost\SQLEXPRESS01
Open SSMS and connect to your (localdb) instance.
Manually create the "AzureStorageEmulatorDb...".
To add yet another answer, I did not have the any MDF or LDF files. Instead, I only had a config file at %USERPROFILE%\AppData\Local\AzureStorageEmulator\AzureStorageEmulator.5.10.config. I also could not connect to my local (localdb) instance with SSMS.
I changed the SQLInstance value in that config file to be localhost rather than (localdb)\MSSQLLocalDB, and it started working.
You should have an app called Microsoft Azure Storage Emulator.
Start this application.
If the application indicates that it is running run AzureStorageEmulator.exe stop first otherwise run AzureStorageEmulator.exe Start directly. Should create your database automatically, at least it did for me.
https://learn.microsoft.com/en-us/azure/storage/common/storage-use-emulator
This seems to be because the mdf file already exists but LocalDB doesn't have it attached. You can delete and recreate as others have mentioned, but in my case I was able to just re-attach it and it worked fine.
Open SSMS to (localdb)\mssqllocaldb
Right click Databases
Choose Attach
Click Add
Select the existing MDF file (mine was in my user profile and named AzureStorageEmulatorDb510.mdf)
Click Ok
Then try running the emulator again.
This solution is not recommended in generally, but you can try it.
I think AzureStorageEmulator by somehow can not full access the localDB whitch setup in directory has limited the permission.
You can go to folder propertiy > sercurity > edit to full permission ( with me directory is user > Appdata).
Then restart the emulator
cmd restart the azure emulator.
Now it worked. You must consider it's unsercurity later on.
I initialized the db instance and succeed, bu my SQLServer is 2017.
Then I search the solution and the doc said delete the trouble database will solve the problem. Maybe you can try it follow the steps in the doc.
Here is my problem:
Every time I start the "Microsoft SQL Server Management Studio", I get a warning
The automatically saved settings file "\\Settings\CurrentSettings-2012-02-13.vssettings' cannot be found.
The message goes on to say :
"You can change this file on the 'Import and Export Settings' Tools Options page". The IDE will use your most recent settings for this session.
Where is this setting? How to fix this?
thanks!
you can try with theses steps :
In the Tools menu, select Options.
Select Environment folder, choose Import and Export Settings
In Automatically save my settings to this file, enter the location you will backup.
Select OK.
This file is in : %userprofile%\Documents\Visual Studio 2008\Settings\CurrentSettings.vssettings
Nota : if you don't find file, you can get another file from your coleague
If SQL Server Management Studio is open close it
Open Registry Editor Navigate to the location
_HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
Server\100\Tools\Shell_
Edit the value of the Reg Key "VisualStudioLocation" to
%USERPROFILE%\Documents\SQL Server Management Studio
Close Registry Editor and check if the problem is fixed
In my case: we have Documents folder as mapped network drive and it seems SQL management studio has issues with that. As a quick workaround I created settings file outside this network drive and it works. Only downside is settings are not synchronized but honestly I don't care :)
Use your favorite registry editor, or use regedt32.exe if you don't have a decent one. Navigate to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<vsver>\profile, where <vsver> is the numeric version of visual studio that you are using, e.g. 6.0, 7.1, 8.0, 9.0. In there, you will find an entry AutoSaveFile. Edit this entry to point to a vssettings file that you want as your default settings file. If you don't have such a file, create one via "Tools->Import and Export Settings...->Export selected environments settings" first. Typical value for AutoSaveFile is %vsspv_visualstudio_dir%\Settings\CurrentSettings.vssettings, and typical value for DefaultSettingsDirectory is %vsspv_visualstudio_dir%\Settings\.
The statement in the error message "You can change this file on the 'Import and Export Settings' Tools Options page" seems to be incorrect. In particular, I was unable to reset the defaults no matter how many different ways I saved or loaded settings using the 'Import and Export Settings' Tools Options page. I had to resort to modifying the registry.
I had the same problem.
Turns out I had renamed the drive and this was causing the problem. Renaming it back to the original (as seen in the path in the error message) fixed the issue.
I managed to fix it with no registry changes.
Based on the instructions from this site:
http://sebastian.expert/the-automatically-saved-settings-file-currentsettings-vssettings-cannot-be-found/
Basically you need to change the default path in options.
Go to Tools/Options then Environment/Import and Export Settings
Change the path to existing one.
I found a lot of solutions which suggested to edit the following registry: HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\100\Tools\Shell\VisualStudioLocation
If there are people(like me) who do not have that entry, I managed to fix it by editing this one:
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\100\Tools\Shell\Profile\AutoSaveFile
I run MS SQL Server 2008 R2
I'm DBA with a new server box running Windows Server 2008 Enterprise SP1 with SQL Server 2008 and SQL Server Management Studio.
In my previous box when working in Visual Studio with database solution with lot of .sql files I used to double-click on the .sql files and they were opened in the same SSMS instance (if any already opened). However (even when having exactly the same installation in the new box) I'm now getting a new SSMS instance when double clicking in each sql file. Its really painful one .sql - one SSMS instance so I started my research about that.
What I've tried till now:
1) Right click on the .sql file > "Open With" option > "Add" option > "Program Name: C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe" and "Friendly Name: SQL" > "Ok" > "Set as Default". Does NOT work. Still having one sql - one ssms instance.
2) Perfomed Run > regedit > and modify the value data of HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\Command and replace /dde with "%1". DOES NOT WORK
3) Right click on the .sql file > "Open With" option > "Add" option > "Programe Name: explorer.exe" and "Friendly Name: Explorer" > "Ok" > "Set as default". Does NOT work. When double-clicking on the .sql files Notepad comes with scripts content.
4) Some pages like this
http://social.msdn.microsoft.com/Forums/en/sqltools/thread/ac2f39c5-66e5-495c-b7a6-47e743853baf
asks to change file association but when opening Windows Explorer > Tools > Folder Options ... I found there is no "File Type" tab. How annoying!
Can someone help me on that? My patient it's really running out.
Thanks in advance
After spending most of my working day looking for the solution I finally found it. Thanks God, I was almost running out with this issue. Hope it helps somebody else!!!.
Update: linked domain expired, so here's what it said:
Considering how integrated Microsoft tools usually are the result is
frustrating when you tell Visual Studio to open SQL files using Sql
Server Management Studio (SSMS). I really don't like using Visual
Studio to edit T-SQL files but in the past, before I discovered this
tip, each SQL file I opened would open in a new instance of SSMS. Try
it:
Open a solution which contains SQL files
Right-click any SQL file and select “Open With…”
Click “Add”
Browse to "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe" or if you're
running x64 Windows "C:\Program Files (x86)\Microsoft SQL
Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe", then click “OK”
Click “Set as Default” and then “OK”
Now open multiple SQL files. Each time you'll get a different instance
of SSMS opened. What a pain!
NOTE: This entire article applies to SQL 2005, just replace SSMS with
SQLWB.
How do you resolve this? Repeat steps 1-3 above, but at step #4 enter
the following values:
Program Name: “explorer.exe”
Friendly Name: “Windows Explorer”
Repeat step #5 (set as default) above and then click OK. Now, open
additional files. They should all open in the same instance of SSMS.
It would seem that Visual Studio issues a command to SSMS.exe which
includes the path of the file selected in the solution explorer. It is
up to SSMS to check for a new instance, which it doesn't. But when you
pass the file name to explorer it gets opened up in the same instance.
QUIRK WARNING!
If SSMS is not already open, the first file you attempt to open (not
first time ever, but every time you open an SQL file from Visual
Studio and SSMS isn't open yet) SSMS will open, but your file will
not. Click the file a 2nd time and it will open the file this time.
Don't ask me to explain it it just is (and I have no idea why).
Conclusion
The result when you tell Visual Studio that SSMS is the default editor
makes sense, but I don't get why it would be different when you tell
explorer to open it. Maybe if I were a Windows developer instead of a
web developer I would know the answer. But either way, now you know.
Enjoy.
I have this problem before, I found there is a simple solution -> just check if your SSMS is under "Run this program as an administrator" option (right click on the shortcut icon -> property -> Compability -> Privilege level). If yes, untick the option and try double click the sql file.
Hope this helps.
Similar issues have been reported multiple times, but they aren't addressing the issue (removed links because Microsoft erased Connect without much thought):
~connect.microsoft.com/VisualStudio/feedback/details/105575/multiple-instances-of-sqlwb-exe-when-management-studio-set-as-default-editor~
http://web.archive.org/web/20130727043341/http://connect.microsoft.com/SQLServer/feedback/details/622181/multiple-ssms-open-for-seperate-sql-files
~connect.microsoft.com/SQLServer/feedback/details/680761/a-new-instance-of-ssms-is-opened-when-trying-to-open-a-tsql-file-even-when-an-instance-is-running~
Did you install Visual Studio (or any Visual Studio components) after installing SQL Server?
My guess is that the Connect items will not be fixed - SQL will blame Visual Studio, Visual Studio will blame SQL, and the items will remain open...
So here is what I suggest: run a repair of SQL Server from Programs and Features and then re-apply the latest service pack of SQL Server 2008 (SP2).
Also the "File Types" interface was moved from the Tools / Folder Options interface to the Control Panel. Go into Control Panel > Default Programs > "Associate a file type or protocol with a program." However it doesn't seem to have the options here to add command-line options like "%1" or /dde.
Try adding these reg keys as well, but make sure you put the /dde back in:
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec]
#="Open(\"%1\")"
For the record, here is my entire export for that section:
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open]
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\Command]
#="\"C:\\Program Files (x86)\\Microsoft SQL Server\\100\\Tools\\Binn\\VSShell\\Common7\\IDE\\ssms.exe\" /dde"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec\application]
#="sqlwb.9.0"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec\topic]
#="system"
Go to Tools >> Folder Options >> File Types and apply below settings. It worked for me finally!!! (after half a day search on google).
Click New/Edit (on this window "Confirm open after download" should be check and "Always show extension" should be unchecked)
In next window, make below entries
- Action: Open
- Application used to perform action : Your ssms.exe path like "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
- Check "Use DDE" check box
- DDE Message : Open("%1")
- Applicajtion sqlwb.9.0
- DDE Application Not Running: Keep it empty
- Topic : system
Regards,
Sandeep Gaadhe
I am using SQL Server Management Studio 2012 Express and I have made this to work by pointing "Program" to "explorer.exe"
This is how my register is set up: "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe" /dde
at
HKEY_CLASSES_ROOT\ssms.sql.11.0\Shell\Open\Command
I've 2005 & 2008 SSMS installed so I defaulted to the 2005 instance. If I have 2008 ssms open when opening a .sql file from windows explorer it will now open in the existing 2008 ssms (and not try to open a new instance!)
From Windows Explorer, one can drag-and-drop selected files (single or multiple) into an SSMS window.
One thing to check is if you have multiple versions of SSMS. If you happen to be working in an older version, double clicking on a file will open the new SSM version. Or whatever the default version is for sql files.
A quick note for users who want to have SSMS always open with Administrator privileges.
Find SSMS in your start menu. Right-click>More>Open File Location.
Once you see the shortcut to Microsoft SQL Server Management Studio * in Windows Explorer, Right-click>Open File Location.
Then Right-click on Ssms.exe>Troubleshoot compatibility.
Then click Troubleshoot program.
Put a tick by The program requires additional permissions then hit Next.
Now it forces you to press Test the program....
Then press Next and then Yes, save these settings for this program.
Arvo Bowen Jan 30 '20 at 15:27
This work perfectly.
I know this is quite an old post and there are loads of different answers with possible solutions. But here's one I think is new (at least to SO).
I suddenly starting getting this behaviour (i.e. each new file would open in a new session) and couldn't figure out why. Turns out it was because in my SSMS session I had an open dialogue which had dropped into the background.
A soon as I closed the dialogue, new files started opening in my original session /facepalm
Maybe everyone knows this already but just in case it saves anyone 20 mins!
My issue with multiple SSMS instances version 19 was fixed by changing HKEY_CLASSES_ROOT.sql Default key to
I am evaluating Oracle SQL Developer.
My tnsnames.ora is populated, and a tnsping to a connection defined in tnsnames.ora works fine. Still, SQL Developer does not display any connections.
Oracle SQL Developer Soars mentions, that if
you have Oracle client software and a tnsnames.ora file already installed on your machine, Oracle SQL Developer will automatically populate the Connections navigator from the net service names defined in tnsnames.ora.
I also tried to set my TNS_ADMIN environment variable, but after restarting SQL Developer there are still no connections displayed.
Any ideas?
Anyone successfully working with SQL Developer and tnsnames.ora?
In SQLDeveloper browse Tools --> Preferences, as shown in below image.
In the Preferences options expand Database --> select Advanced --> under "Tnsnames Directory" --> Browse the directory where tnsnames.ora present.
Then click on Ok,
as shown in below diagram.
tnsnames.ora available at Drive:\oracle\product\10x.x.x\client_x\NETWORK\ADMIN
Now you can connect via the TNSnames options.
This excellent answer to a similar question (that I could not find before, unfortunately) helped me solve the problem.
Copying Content from referenced answer :
SQL Developer will look in the following location in this order for a tnsnames.ora file
$HOME/.tnsnames.ora
$TNS_ADMIN/tnsnames.ora
TNS_ADMIN lookup key in the registry
/etc/tnsnames.ora ( non-windows )
$ORACLE_HOME/network/admin/tnsnames.ora
LocalMachine\SOFTWARE\ORACLE\ORACLE_HOME_KEY
LocalMachine\SOFTWARE\ORACLE\ORACLE_HOME
If your tnsnames.ora file is not getting recognized, use the following procedure:
Define an environmental variable called TNS_ADMIN to point to the folder that contains your tnsnames.ora file.
In Windows, this is done by navigating to Control Panel > System > Advanced system settings > Environment Variables...
In Linux, define the TNS_ADMIN variable in the .profile file in your home directory.
Confirm the os is recognizing this environmental variable
From the Windows command line: echo %TNS_ADMIN%
From linux: echo $TNS_ADMIN
Restart SQL Developer
Now in SQL Developer right click on Connections and select New Connection.... Select TNS as connection type in the drop down box. Your entries from tnsnames.ora should now display here.
I had the same problem, tnsnames.ora worked fine for all other tools but SQL Developer would not use it. I tried all the suggestions on the web I could find, including the solutions on the link provided here.
Nothing worked.
It turns out that the database was caching backup copies of tnsnames.ora like tnsnames.ora.bk2, tnsnames09042811AM4501.bak, tnsnames.ora.bk etc. These files were not readable by the average user.
I suspect sqldeveloper is pattern matching for the name and it was trying to read one of these backup copies and couldn't. So it just fails gracefully and shows nothing in drop down list.
The solution is to make all the files readable or delete or move the backup copies out of the Admin directory.
This helped me:
Posted: 8/12/2011 4:54
Set tnsnames directory
tools->Preferences->Database->advanced->Tnsnames Directory
https://forums.oracle.com/forums/thread.jspa?messageID=10020012�
On the newer versions of macOS, one also has to set java.library.path. The easiest/safest way to do that [1] is by creating ~/.sqldeveloper/<version>/sqldeveloper.conf file and populating it as such:
AddVMOption -Djava.library.path=<instant client directory>
[1] https://community.oracle.com/message/14132189#14132189
I've created a dtsx package with Sql Server Business Intelligence Development studio, and I am executing it using the dtexec utility. Using dtexec I am setting certain properties at runtime using the /set switch. So my command looks something like:
dtexec /f "mypackage.dtsx" /set
\Package.Connections[Destination].Properties[UserName];myUserName
This works perfectly when I run it on my local system (the one it was developed on). Unfortunately, when I copy this package to a different system and attempt to run this exact same command, I receive the following error:
Warning: The package path referenced an object that could not be found:
\Package.Connections[Destination].Properties[UserName]. This occurs when an
attempt is made to resolve a package path to an object that cannot not be found.
The new system that the package was moved to has SSIS installed and is running the same version of Sql Server as my local system (SP2). Maybe I'm misunderstanding something about the intended use of dtsx packages, but I really don't see how/why this is happening.
This steps is for creating an XML configuration file (.dtsConfig) which can keep your sensitive data, like the password of your connection string, without having a Protection Level that can make you difficult to move the package from one machine to another.
In this example, assumed you have an OLE DB Connection to an SQL database called MyDb.
Control Flow, Property: set "ProtectionLevel" to "DontSaveSensitive"
Control Flow, right-click empty space to get menu: click "Package Configuration"
Package Configuration Organizer: tick "Enable package configuration"; click "Add"
Package Configuration Wizard, Select Configuration Type: set "Configuration type" to "XML configuration file"; choose "Specify configuration directly" radio button; click "Browse..."
Select Configuration File Location, fill "Filename": [PackageName].dtsConfig (easy if same folder and same filename as the package itself, just different extension); click "Save"
Package Configuration Wizard, Select Configuration Type: click "Next >"
Package Configuration Wizard, Select Properties to Export: traverse the following tree nodes and tick its checkbox; click "Next >"
\[PackageName]\Connection Managers\MyDb\Properties\Connection String
\[PackageName]\Connection Managers\MyDb\Properties\Password
Package Configuration Wizard, Completing Wizard, click "Finish"
Package Configuration Organizer: click "Close"
Solution Explorer: right click the root tree for menu, click "Add", "Existing Item...", click [PackageName].dtsConfig, click "Add"
Solution Explorer: double click \Miscellaneous\[PackageName].dtsConfig to load into editor;
Main menu: click "Edit", click "Advanced", click "Format Document"
Traverse the XML tree node: \DTSConfiguration\Configuration[Path="\Package.Connections[MyDb].Properties[Password]"]\ConfiguredValue; key in the database password; save the file
Windows Explorer: navigate and double click [PackageName].dtsx
Execute Package Utility, Configuration, click "Add", double click [PackageName].dtsConfig, click "Execute"
When required to move the .dtsx to another machine, simply accompany it with its .dtsConfig. Hope this helps.
Cheers, Ari.
You'll need to create a deployment utility if you;re moving the package between machines. Your connection information gets encrypted using a key specific to your machine.
If you go to the project properties in VS, Select the deployment utility section and set the CreateDeploymentUtility option to true. This will create the deployment utility in the bin folder, you can then copy all that to the new machine, run the installer, and all should work fine.
The quickest way to move packages between machines and avoid all the signing of the packages is the following.
In Visual Studio with the package open select "Save copy of PackageName" As
You then get a wizard up. Easiest one is probably to just select file store. Then at the base of the wizard you will see protection level. Select Encrypt Sensitive data with a password. Enter a password.
On the server you wish to move it to select Import Package and it will prompt you for the password. Enter it and your connection information will be correctly move to the new server.
Definitely not best practice but it is a good method for quickly moving things around test servers.
On your control flow properties, there is a property called "ProtectionLevel". If you set this to 'DontSaveSensitive' then that might cause you less headaches while doing dev and testing. For production scenarios where security is a requirement then you might need to find another solution.
Here are the guidelines from MSDN about package security. Setting the Protection Level of Packages