I have Visual Studio 2005 (BIDS) set to "Check out automatically" when a file is edited which works well for most file types.
When I access a Data Flow within an SSIS package though, a check out is triggered without me making any changes. When I compare the files, there does not appear to have been any changes made in the background either.
This behaviour is annoying because I lose track of which files I actually made changes to and because I am potentially taking locks on files that I am not interested in editing.
I only found one reference to this problem while researching it on the net but there was unfortunately no solution provided. I can confirm that the problem appears to be related to conditionals (as described in Daniel's post).
I changed from "Check out automatically" to "Prompt for checkout" but was then presented with a series of prompts which I needed to cancel before I could actually view the data flow.
Is there any way that I can prevent these files from being automatically checked out without having to face all of the prompts?
Scott, try Tools - Options - Source Control - Environment and select "Do nothing" option in Editing drop-down.
This option will allow you to view the data flow without prompts, but you'd have manually checkout files before you'd be able edit them. See if it works for you.
Related
I am taking over a SSIS package which was developed and running on another server, say Server-01. I am working on this package with MS Visual Studio 2008.
Now, I am trying to run it on my server Server-02.
So I changed the settings of some SQL Task boxes and their related data sources from Server-01 to Server-02, then pressed the OK. After this, I closed the setting panel and reopened it, it looks fine, all my changes have been recorded.
Then I run the boxes in Development mode. As it stopped, I open the boxes which I've changed, then find everything was changed back to its initial status.
May I know what is wrong with my operation, and how can I over come it?
Thanks.
After wrestling with the problem for a while, here are two methods I found. They may not formal, but it suits my case.
Method 1: I went to SSIS->Variables, then change the value of the variable there.
Method 2: I had one variable which cannot be changed via above method, so I opened its property panel, and changed the expression and assigned a new value to it.
Please correct me if my understanding is wrong, or if there are better ways to settle this.
Thanks a lot.
I have a tabular model that I've processed and deployed.
I'm having a problem getting SSRS to reflect the newly deployed information. I have a shared Dataset accessing a shared Data Source. When I run the MDX in the query designer of the Dataset, the correct numbers are returned. When I run the report, however, the old numbers still show. I've tried deleting the .DATA file but it didn't help.
EDIT:
I've verified that the problem is in the SSAS database itself. I queried it with drillthrough from SSMS and saw that it is returning rows that aren't in the source views any more. They used to be, but no longer.
This almost seems to be some crazy caching issue. I've rebooted and dropped/redeployed the SSAS database and no luck.
Any thoughts?
I would suggest a few steps.
Ensure you are connecting to the correct tabular model.
Expand the tables in the tabular model, and right click one of the tables and click "Process". Check all the additional tables in the model.
Change "Process Default" to "Process Full" (Process default does not always work correctly)
Click Ok.
You should now see the model process table by table.
I would close and re-open the report.
Actually I would completely ignore the BIDS / Visual Studio Preview pane as it is riddled with bugs and inconsistencies and proves nothing (assuming your end users aren't using Visual Studio).
Instead I would deploy the report for each test run to a test environment / folder on the host server (Report Manager / SharePoint). As well as being a realistic and meaningful test, this has many advantages such as being able to leave multiple IE tabs open with various parameter combinations set, then just refresh them after a Deploy to retest.
Been struggling with this for quite some time so any help is appreciated. Spent a lot of time looking over MSDN, Google, etc, and still no luck.
I have an SSIS project I intent to always execute from within BID. The project has multiple packages, so I created a Data Source to share amongst all the packages.
In each package, I create a Connection Manager based of that Data Source. Now when I go and edit this Data Source's connection string to point to a different server, the change is NOT reflected in the packages.
Now, MSDN says the opposite. In fact, one of the main purposes of Data Sources is to update connection strings easily from within BID; at least according to MSDN.
And for me its not working. This has got to be the most annoying thing I have seen thus far in BID.
Any one have any suggestions?
UPDATE
It looks like BID does not synchronize a Data Source change with Connection Managers if the data source's authentication is SQL server. If it is Windows authentication, it detects the change fine.
Very interesting indeed.
Just a guess. This kind of behavior happens when you have a "package configuration" configured.
Right click on any blank area of your control flow and select "package configuration". If the "Enable package configurations" check box is selected and you have a configuration on your connection string, it will override any value you had specified manually.
I figured it out for those that are interested. I am not sure if this is a bug in BID or not but I hope this helps someone else struggling with this problem.
All you have to do is simply open up all your packages at one time. This is as simple as highlighting all the packages in the solution, right clicking, and choose "open".
Once all the packages have been opened, go ahead and edit your Data Source's connection properties. BID will automatically apply the new changes to all the open packages that have a connection manager based on that Data source.
Hope this helps someone.
I found I could not change any of the data connection configuration values because there was a variable defined for the connection string. Enabling/disabling package configurations had no effect on the behavior.
To access the variables menu, right click anywhere on the DTSX designer background and select Variables. Make sure you do not have any values in the variables list that are being referenced by your data connection. If you can not find the references anywhere, try fixing the values for the variables that might be affecting it.
You need to change in respective dtsx package. Open it in notepad++ and search for the connection string, modify it and save it. You can see the connection change in solution now.
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
Whenever I wish to debug a single report (.rdl file, Report Definition file), it always deploys everything in the solution. Can someone recommend a deployment strategy in order that I can localize deployment to the specific report I am working on, and not clobber the other reports in the solution? Those may have been worked on by another employee, and why should deployment occur across the board?
Right clicking on the specific report to deploy and choosing "Deploy" from "Solution Explorer" always works for me. Also, I keep OverwriteDatasources to false unless I specifically need to update that.