I would like to add the following variable from a script task:
"IndexLocation"
String
Value: "http://www.mypage.com"
'Ex.
dts.variables.add("daf")
--Obviously above does not work
You can add variables to a package using Dts.Variables.Add, but I've never tried it myself - wondering why you'd want to create them dynamically in the package rather than set them up in the Variables pane?
How will these variables be used?
If you're adding them programmatically, other components/tasks will not be aware of them, as you would not have set them up during design time.
Or are you accessing them in another script task, which assumes they have been created?
The general practice is to create variables at design time.
Adding variables at runtime could play havoc on variable locking and other internal ssis workings - you can't guarantee the reliability and accessibility of the variable.
Related
Good afternoon,
I am trying to create a variable in MySQL (5.7), that will persist through restarts. It appears that user created variables will not give me the ability to accomplish this so I am looking at the global variables. These appear to be built-in to MySQL and I cannot seem to find a way to create a new persistent variable.
How can I create a global/system variable in MySQL (5.7) that will persist through restarts?
There is no simple way through the SQL interface or configuration to create new system variables -- they are, after all, "system" variables. Any solution to this that comes to mind would be an advanced operation, like one of these:
modify the MySQL server source code to create a new system variable
modify the MySQL server source code to reintegrate the "deprecated" logic from prior versions, where the old variable and new variable behave the same but the old variable throws a warning when you use it
write a MySQL plugin (in C) whose only purpose is to expose a new system variable, basically a dummy variable that doesn't actually do anything, other than having a default value and maybe being (or giving the appearance of being) writable if needed, in order to keep the application happy
We have a large number of access databases that contain a number of common functions. We need to make a small change to one of the functions, and are looking for a way to automate this via scripting, etc. Is there any way to get at the VBA code inside an Access database, and make a change to it?
I have used ADOX before from PS or VBS to be able to list tables, views and queries, but it does not expose the VBA code in its API.
~bp
If the code changes are always in a module with a consistent name then you can simply remove the existing module and reimport the new version in all the projects you need to apply the change.
http://www.cpearson.com/excel/VBE.aspx
The above link posts information on how to import modules into a VBA project. So simple case of looping through your multiple databases and removing the module and importing the latest version.
If the code changes are located in different module names, you can open each database and loop through the modules to search for the string. The functions you'll need are listed here (depending on the style of change, it'll most likely be some combination of Find and ReplaceLine)
http://msdn.microsoft.com/en-us/library/office/aa223124%28v=office.11%29.aspx
In David Fenton's answer to the question "MS Access (Jet) transactions, workspaces" he states:
I would also say, never pass the workspace -- only pass the objects you've created with the workspace.
Is passing the workspace a bad idea? If so, why?
Additional info:
My intent here is to execute INSERT/UPDATE/DELETE statements from within multiple Subs/Functions but wrap them all in a single transaction.
The base functionality is wrapped up in a class module. I want to be able to isolate multiple instances of the class module, which means I can't just assume my transactions are executing against the default workspace.
In SSIS... is it possible to access and change the package itself from one of its script tasks? If it is... could you please provide an example?
For instance, I would like to programmatically configure the tasks within a foreach loop from a script task located outside (before) the loop. Something like reading a file and add/removing/configuring tasks depending on its contents.
Thanks for your time!
As #Derek had already mentioned, it is not possible to alter the package itself. However, you can use precedence constraints/Expressions to alter the behavior of Control Flow tasks based on the value present in variable(s), if that is what you meant by altering a package.
Here are few examples where I have used precedence constraints to redirect/restrict the control flow tasks based on an expression:
How to loop through only files that don't exist in destination using an SSIS package?
How can I stop a package execution based on a stored procedure output?
How to avoid SSIS FTP task from failing when there are no files to download? (This example uses a script task followed by a Foreach Loop container.)
How to write an SQL statement output to a CSV file?
Hope that helps.
No, that's not possible - however, I do something very similar by utilizing a second "child" package that I reuse numerous times. In the script you can simply clear out the child package, put all of the items/containers/constraints you need into it, and then execute it.
I'd like to pass a Data Flow from one package to another for the following reasons:
It would help in refactoring common
logic in SSIS packages.
It would enable concurrent
development of larger SSIS packages.
At first glance, the Execute Package Task sounded promising, but it looks like I can only pass fairly simple variables in and out of the package.
Is there a way to do this using SSIS?
cozyroc.com is a third party tool that can do this I believe.
A bit of clarity Paul, are you talking about 1) code reusability or 2) allowing the results from one DFT to be used in another DFT?
The first you can't do in "native" SSIS I believe - a set of DFT modules that you can call from other packages, but I would approach it as building a set of packages that are quite simple
initialision routines
DFT
cleanup
Then having variables passed to the child package that are (e.g.) table to be processed, variable(s) to be selected from the source table.
It would requrie a very clever schema and some clever thinking about what the common DFT would do. But I think it would be possible.
The second is not possible without jumping through a few hoops - like saving result sets to temporary tables then re-reading the tables into later DFTs, but then you would loose the data actually flowing through the task.