I am calling a stored procedure in a data flow task that outputs a value that is not being used. Because its not being used the optimizer removes the component during runtime. It states I can override this by setting the 'HasSideEffects' property to true but I don't see where to set this. I see it in the 'Input and Ouput Properties' of the OLE DB Source but its read only.
Turns out that I had set the 'RunInOptimizedMode' property to true and that was causing the issues. Set it to false and I am good to go
Related
RetainSameConnection property on project-level connections.
If I change to true (from default of false) and choose not to save the package file I used to make the change then the setting will be retained but none of the files in source control have changed. Where is this value being stored?!
Value is stored even after closing/reopening VS and restarting machine.
Also:
If you specify RetainSameConnection=true at the project-file level (.dtproj) the RetainSameConnection property drop-down (viewed via Properties tab) in VS will show false but the behaviour will be true. While I would expect behaviour to be true it's misleading that the drop-down value doesn't conform & I'd like to understand why it doesn't.
If you create a boolean project param with value of true & parameterise RetainSameConnection property of the project connection then behaviour will be true and you can no longer change the value of the drop-down. This is exactly what I'd expect.
If you edit and save the connection properties it will set DTS:Retain="True" on the conmgr file. This again doesn't cause the drop-down value to change. haven't experimented with this as am losing the will slightly.
I'm trying to loop through excel files in a directory and perform a data flow task in SSIS.
The For-Each Loop container seems pretty simple to set up:
I map to a variable called FileNameTemp.
Inside the For-Each Loop, I have a data flow task where the source object is an Excel Source with an Excel Connection Manager. I use the FileName temp to set the File Name of the ExcelFileName:
My problem is whenever I try to run the package, I get the error below:
[Connection manager "Excel Connection Manager"] Error: SSIS Error Code
DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code:
0x80004005. An OLE DB record is available. Source: "Microsoft Access
Database Engine" Hresult: 0x80004005 Description: "Failure creating
file.".
I found other similar posts. I definitely have permission to write to this folder. If I remove the expression and just open the same file over and over it works. I also set DelayValidation to true on pretty much every level.
Try removing the "C:..." from your expression definition. The For-Each file enumerator will give the full path.
In the future you can set a breakpoint on your data flow task and view the value of your variable that you set in the locals tab.
Same answer, just more verbose than #mike Baron's answer is that in the ForEach Loop Container, the radio button is checked for "Fully Qualified" with the result pushed into our variable #[User::FileNameTemp]
Each file found in the specified source folder C:\SourceCode\ExcelSourceFinancialReconcilliation is in turn going to be assigned to that variable in the form of
C:\SourceCode\ExcelSourceFinancialReconcilliation\file1.txt
C:\SourceCode\ExcelSourceFinancialReconcilliation\file2.csv
C:\SourceCode\ExcelSourceFinancialReconcilliation\file2.xls
Then, when we set the Expression on the Excel Connection Managers ExcelFilePath property, we need to just use #[User::FileNameTemp] As it stands, the expression is doubling up the path so that Excel is attempting to find
C:\SourceCode\ExcelSourceFinancialReconcilliation\file1.txt\C:\SourceCode\ExcelSourceFinancialReconcilliation\file1.txt
As a general rule, only use a direct variable in the Expressions associated to "objects" in SSIS. Property1 = #Variable The reason for this, is that you cannot put a break point to on the evaluation to determine why #Property1 = "Foo" + #Variable is invalid. If you create a custom variable #Property1Variable = "Foo" + #Variable and then assign #Property1 = #Property1Variable, you can put a breakpoint in the package and then inspect the value of the SSIS variable. It's much easier to find problems this way.
Possibly helpful other answers on the subject
https://stackoverflow.com/a/18640174/181965
https://stackoverflow.com/a/21536893/181965
I've created a function that attempts to return a SubForm data type. This function is used by various parent Forms.
The function looks like this:
Public Function mySubFrm(name As String, subformName As String) As SubForm
Dim frm As Form
Dim subFrm As SubForm
Set frm = Forms(name)
Set subFrm = frm.Controls(subformName)
mySubFrm = subFrm
End Function
I've attempted to use it by the following:
Dim testSubForm As SubForm
testSubForm = mySubFrm("testForm", "testSubForm")
Immediately, it follows with compile error:
Invalid use of property
What I've attempted to do was add a watch at frm.Controls(subformName) and I see its return type is SubForm/SubForm, so I feel as though I am declaring and setting the right data type, but then again I'm not sure?
Can someone assist me with what I'm not doing properly?
Thanks
I don't know much Access, but I know VBA pretty well.
Your function is returning an object reference:
Public Function mySubFrm(name As String, subformName As String) As SubForm
As such, its return value must be assigned using the Set keyword:
Set mySubFrm = subFrm
The reason why you're getting this confusing error, is because of a lovely (not!) thing in VBA called default properties.
See, a form has a default property, most likely its Controls collection - and that property is only exposing a Public Property Get accessor, which makes it read-only.
So when you omit the Set keyword:
mySubFrm = subFrm
VBA assumes the code is legal, and so the only thing you could possibly be wanting to do, is to assign that default property - in other words, it's behaving exactly as if you would have written:
mySubFrm.Controls = subFrm
But the Controls class' own default property is its Item member, which is also read-only: there's no way the default Controls property can appear on the left-hand side of an assignment.
Hence, invalid use of property.
My open-source project Rubberduck will soon have an inspection that will issue a result whenever you're implicitly referring to an object's default property, offering to make the call explicit. Writing code that says what it does, and does what it says is hard when you don't even know you're referring to a default property.
You receive the error because you're trying to set an object, but are not using the Set keyword.
Perhaps it should be the following:
Set mySubFrm = subFrm
Or
Set mySubFrm = frmDatasheet
I would like to suggest a different approach. Typically when you create a form with a subform, it's quite rare that you actually need the subform to be dynamic. There is almost always a relationship between the parent form and the child form, and I would consider a parent form without its child a broken object in general.
Therefore, when I need to access things that's on the subform, I prefer to use the explicit version:
Dim mySubForm As Access.SubForm
Set mySubForm = Me.Controls("mySubForm").Form
mySubForm.SomeControlOnMySubForm.Value = 123
Yes it's 3 lines now but the advantage is that the reference to a specific form is now made explicit in your parent form. You now can see from the code that the parent form depends on that subform. More importantly, if you delete or rename the control SomeControlOnMySubform, the above form will allow the VBA compiler to warn you that there is no such object on the subform, enabling you to verify your code.
In other words, try your best to convert any potential runtime errors into compile-time errors because compile-time errors are much easier to validate and prevent than runtime errors.
The same principle works in the reverse; when you want to describe your subform as explicitly depending on a parent form, you can do:
Dim myParent As Form_frmParent
Set myParent = Me.Parent
NOTE: The code all assumes that there are code-behinds for all forms involved. If a form has no code-behind, it won't have a VBA class for you to reference. In such case, I set the form's property HasModule (located in the Others tab) to Yes even if there's ultimately no code-behind. (The reason is that it used to be that you could create "lightweight" form by creating it with no code-behind but with modern hardware, there is hardly any difference)
I am using EzAPI to build an SSIS package.
FlatFileSource -> DerivedColumn -> ODBC Destination.
But I can't find where to set the Delay Validation property to true. It's not letting me do so in the EzPackage or EzDataFlow objects.
In Visual Studio, the DelayValidation property may be set for a FlatFileSource, but there is no DelayValidation property available for either a DerivedColumn component or an ODBCDestination. On which object do you want to set the DelayValidation?
I was able to set it by casting the EzDataFlow object to a Microsoft.SqlServer.Dts.Runtime.TaskHost object
EzDataFlow dataFlow = new EzDataFlow(Package);
((Microsoft.SqlServer.Dts.Runtime.TaskHost)dataFlow).DelayValidation = true;
When i tried to give connection string in the form of a variable to "Excel Connection Manager", it gives me the below error.
the connection string format is not valid. it must consist of one or more components of the form x=y seperated by semicolons. This error occurs when a connection string with zero components is set on database connection manager.
Since you want a dynamic file path, when you are setting up the Expression for the Excel Connection Manager, you are probably selecting ConnectionString as a property in the Property Expressions Editor. This results in the error you specified in your question.
What you actually need to select is the ExcelFilePath property. Add your variable in the Expression field afterwards as you would normally do.
You should give us more information. What's the value of you variable when the error pops up? To exactly what property have you assigned this variable?
Anyway, I suspect that you didn't set [Delay validation] property of your connection manager to True - without it ssis check if you connection manager is ok, before you even assign value to the variable (which is dynamic and happens during execution in some loop, I suppose).