I am trying to set up deployment process for single package usinig project deployment so VS2012. I found that to change dynamicaly connection string on the server I can parametrize connections so I did this and created enviroments and I run my package with inviroment which has connnections strings as parameters and all seems to be fine, but why on connection manager I can still see some old setup made while developing? How can I remove it ?
By Parameterize, I assume you're using the Configuration section to globally configure a project/package or on a per-execution basis. This is in contrast to using project/package Parameters
I have created an SSIS Environment variable named ConnectionStrings in my deployment folder and it has two values: ServerName and CatalogName.
I right clicked on my project, DeployMe, and selected Configure. In your screenshot, you have clicked on the specific package and selected Configure. That or you manually changed the Scope drop down.
I first click on the References and add a pointer to my Environment
Back to the Parameters tab, I click over to Connection Managers and I'm going to configure the CM_Project connection manager's ServerName property to use my environment variable's ServerName value. Clear right?
After configuring the ServerName, I also configured the InitialCatalog property but instead of using my Environment Variable's value, I used the "Edit Value" option (above) to set it. The net result is that my properties now look like this.
The underscore indicates it's set from an environment variable
The bold text indicates it's set manually.
Now when I go to run my package, via Agent or manual execution, the first thing it's going to prompt me for is an environment reference. I've lost my bolding for the InitialCatalog but the underlining remains for ServerName property. None-the-less, both are different values and were I to execute it, they would pick up the correct values.
All that said, I find it far easier to just store the whole ConnectionString value. You will observe, if you take this route, that the values displayed for ServerName would show your design-time values but that's fine because the ConnectionString as a whole will override the individual values at run-time.
I know this is a generic answer but I'm hoping I've hit on what you're missing step-wise.
Related
I'm having problems when using the option "Get values from a query" in my Parameter settings.
On the server everything works like a charm.
But when I deploy and then launch the report on my hosting, I get an error message:
If I use the option: "None", then everything works fine.
I've placed a test Tablix, to see the result of the dataset on the host, and also this causes no problem.
So the issue is only with the "Get values from a query" section AND only on the hosting.
Anybody got an idea?
EDIT: I turned EnableRemoteErrors on, as requested by the errormessage, but no additional info is given.
The detail of the error is in the SSRS log file located at -->
<SSSRS_INSTALL_DIR>\Report Server\Log Files.
That is where I would go. Based how you describe the dataset driving the parameters works but not when given a value then I would expect this to be a parameter mismatch or missing parameter. Make sure that you are feeding the dataset the parameters you think you are. Also, if you don't allow nulls then make sure you are supplying a default value.
You said, you placed a tablix on the report showing the results of the YearsDOW dataset and this fails. If this also fails when you set your available values to 'None' then we can assume, as the error states, that the issue was with executing the query itself, not your report design.
As this seems to work when you run it from your local machine in development but fails when run from the server I would suspect it's an authentication/permissions issue.
Check the credentials on the datasource in your development environment and compare these to the SSRS server's version of the datasource. Remember, by default datasources do not get overwritten so it maybe that you deployed the datasource initially with one set of credentials then then changed them in your development environment.
If this is the case and the datasource is not used for other reports on the server, then you can either change the project properties to overwrite datasources but personally I prefer to delete the datasource from the server and then redeploy, that way future changes won't affect the servers version unintentionally.
If the datasource is used in other reports without problems then you could just rename the datasource to something unique so it will get redeployed under the new name and your report will point to that new version.
I have project where there is allready connection manager created called ODS, and this connection manager used domain account before, now I have to switch it to user and password, the problem is that when I simple go to edit and change it doesn't work, but when I create new then it works. I saw that there are two icons near the connection manager, red arrow and fx , what does it mean ?
Edit:
OK I assume that fx means that it is parametrized and red arrow means problem with connection. Unfortunally there seems to be a bug, when connection manager is paramterized and there is connection string in parameter it doesn't work locally.
Cause:
Your connection manager goes offline when you make a change to the connection string that is incorrect, ex. spelling error in the server name, and the system can not validate the connection.
To fix it:
Correct the mistake in the connection string
Right click on the connection in the connection manager and un-select the "Work OffLine" option. This remove the "Red Arrow" icon and make your connection "live" again.
The red downward facing arrow indicates that the resource the connection manager is using is offline or unreachable in some fashion.
I believe you are stating that when you manually edit the connection manager, it doesn't work/persist and that is due to the Expression overriding the values. To resolve this, right click on your project level ODS Connection Manager and choose properties. Click the plus sign on the Expressions property and from there, you can identify the Variables and/or Parameters that are actually setting the values.
A Variable will take the form of #[Schema::VariableName]
A package level parameter will take the form of #[$Package::ParameterName]
A project level parameter will take the form of #[$Project::ParameterName]
Once you have identified the source of the Expression, then you will go to the Variables Pane (View -> Other Windows, Variables); Parameters tab at the top of the package; Projects.params and change the values there.
If all of that has the correct values, then you may be running into an incompatibility with your Project and packages' Protection Level. If it's DontSaveSensitive, clicking Save might result in the password being removed. I haven't worked with SQL Logins for some time so I don't know for sure how they will behave. You might be able to set the password, if it's a parameter, as Sensitive and see if that doesn't make it better. Might make it worse as there are strict rules about how you access a Sensitive parameter versus a non-sensitive.
Finally, the fx glyph signifies there is an expression somewhere on the connection manager. While it's likely on the ConnectionString or the individual components of database name, user and password, I've seen people use expressions on more esoteric properties.
the answer was to take connection manager ofline and connection manager worked for me in this format Data Source=xxx;User ID=xxx;Password=xxx;Initial Catalog=xxx;Provider=SQLNCLI11.1;Auto Translate=False;
I have just started looking at using the SSIS 2012 Project Deployment. One thing I have noticed is that once the project is deployed all the properties relating to the project level connection manager get deployed too and hence need to be configured (Linked to SSIS Environment Variables).
Was just wondering whether the SSIS environment is smart enough to infer the ConnectionString property from the InitialCatalog and ServerName properties. That way I would only need InitialCatalog and ServerName Environment Variables and not a third variable containing the actual connection string which would result in a duplicate configuration.
Please see screenshot below showing an example of this.
If I got your question right, you want to set the initial catalog and server name property paramatically.
Here are the steps to do it: [Applicable for SSIS 2005 and above]
Step-1: Create two variable in SSIS package (Package scope) and name them DbName, ServerName
Step-2: In connection manager, create a OLEDB connection and test connection.
Step-3: Now, right click on the connection manager and click properties.
Step-4: In properties, click expression. You will see below window. In this window select initial catalog
Step-5: Now click on expression and drag drop DbName (i.e. your catalog name) variable from upper left window to expression text box and evaluate it.
Step-6: Do the same for Server name. and you are done
Remember: If your initial catalog and database parameter name are not
correct then you may face connection issue.
Other way, Specifically for SSIS 2012 and above
Now, as you have mentioned SSIS2012. Let;s utilize its feature of Project parameter
Create project level variables, You can either create two variable names [DBName, ServerName] or complete connection string.
Create OLEDB connection in connection manager and right click on the connection. Then select, "Parameterize"
Based on your parameter, you can set parameter to properties like Initial catalog, Server Name, Connection string etc. Or you can create project level parameter from here by selecting appropriate values, as shown below
Read this link for more details
I tested several combinations of ConnectionString, InitialCatalog and ServerName. It looks like servername (DataSource) and initialcatalog have to be in the connection string and the initialcatalog has to have a value. If I left servername blank it worked as long as DataSource was in the connection string.
I want to develop SSIS package in which I want to copy files from FTP location. This location will be configurable. I want that if FTP location is down due to any reason or not available then it will be able take files from some alternate FTP location. Please let me know how this can be achieved.
Precedence Constraint approach
Add an FTP task, Primary FTP, and then add a second FTP, Alt FTP. Connect the second to the first through a OnFailure constraint.
Loop approach
Create an integer SSIS Variable, FTPTryCount assign it to zero.
Add a string Variable, FTPConnectionString with EvaluateAsExpression = true and use an expression like
(#[User::FTPTryCount] ==0)?"PrimaryFTPString":"AlternateFTPString"
If the value of FTPTryCount is zero, then we'll use the first connection string. Otherwise, we use the second string. Make those value connection strings for your system.
Configure the FTP Connection Manager to use the string from #[User::FTPConnectionString]
Add a boolean Variable FileFound and set it to false.
Add a For Loop. Terminal condition is #[User::FTPTryCount] > 1 || #[User::FileFound]
If we find the file or have tried twice, we want to exit the loop.
Inside your FTP Loop, you'll have an FTP Task and a Script Task. The Script Task will be in the OnSuccess path and all it does is set the FileFound to true.
Script approach
Assuming the variables from the Loop approach exist, add a script task that will set the #[User::FTPTryCount] check the FTP Connection manager's connection string and then attempt to open a connection to it. Wrap it all in a try/catch block. If the connection opens, FTPTryCount remains 0. If the catch block fires, then you set it to 1.
From the Script Task, add your FTP task. Configure the FTP Connection Manager to use the string from #[User::FTPConnectionString]
Error handling regardless of approach
The FTP task will fail if it can't connect to the remote server (or if no file is found). You'll need to handle this otherwise it's no good.
This is all high level, I have no access to an FTP site so you're on your own for physical implementation of the design but any of the above should work fine.
I want to add a parameter to a step that runs an operating system (CmdExec) in SQL Server Agent. I have searched everywhere and asked my coworkers and none of them had tried it before. I have attached a picture of the screen. I was thinking that I might be able to add the parameter (file path) after the .exe statement, but wasn't sure.
I thought the following might work:
Executable Path Parameter Path
C:\MyProgram\MyApp.exe E:\AppInfo\Client\Config.txt
This is on a production server and I didn't want to break anything if this isn't correct.
Thanks!
Yes You can use parameters, so your command would be:
C:\MyProgram\MyApp.exe E:\AppInfo\Client\Config.txt
If there is a space in the name don't forget to use quotes as specified in tip in screenshot:
"C:\My Program\MyApp.exe" "E:\App Info\Client\Config.txt"
Since You want to try it on production server, consider testing your configuration and software on test environment first. If You doubt that this will work, You can set job to execute only this single step to make sure it will work as expected.