I have a Source Script Component in SQL2012.
I believe if you want to set a Read/write variable in the Scriptcomponent it must be set in the Postexecute method . And I have done so like this;
public override void PostExecute()
{
base.PostExecute();
Variables.value1 = "some value";
}
I tested the variable after the script component ran and found it hadn't been set. I set a break point in the PostExecute method and confirmed it never gets called.
I even wrote a very simple new package and tested it again with the same results. Can anyone tell me why the PostExecute will not fire.
I'm not aware of any restrictions on seting a variable here (regardless of if there are records to process or not).
The variable can be set in the script component, but you can only use it after the Data Flow task is finished (in the next task).
After some testig it appears that when you use a script component as a "Source" the PostExecture event never fires. Works fine a "Transformation". Didn't test out "Destination" type. Nothing in the Microsoft documentation mentions this fact so it's missleading.
I ended up using the rowcount control to count records. Not sure what I would have done if i had needed to to more on the PostExecture event.
I have used a Script Component as a source many times and PostExecute does fire.
Related
I have created a test with 1 action which contains n actions. Is there any way to check after the execution of each action of the n actions the result if it is fail or pass and proceed accordingly?
Not directly.
A similar idea would be to ask for the current run result status, see How can I get the run result status according to the current report node?, but that is currently unsolved.
You can, however, call your actions, and consume there return value, like this:
ActionSucceeded=RunAction ("myTest [Action2]", oneIteration)
If not ActionSucceeded then
' The Action2 call signalled "failure" (false)
End If
This implies that Action2 must return such a result, like in here:
ExitActionIteration (false)
Beware, however, of the fact that RunAction statements need to be inserted using QTP´s IDE (Insert/Call To Action...), resulting in a RunAction call without brackets. When editing this to the assignment form above (with brackets), make sure you get it right the first time before you save the test -- because if you save a test containing a broken RunAction call, QTP disassociates the called test, and the test will fail at runtime even if you edit the script back to correct syntax. This is due to metainfo that QTP saves invisibly in the script, and if you save an invalid action call, this metainfo is being discarded. (You can see when this happens because the action call will disappear from the test flow view.)
And: If you don´t store the RunAction result in a variable, but use it directly, like in
If not RunAction ("myTest [Action2]", oneIteration) then
' The Action2 call signalled "failure" (false)
End If
the same mess arises: QTP does not understand that this is a valid action call, and it won´t work even if you edit it into back into the original form.
Except for the "beware" hint, the same holds true for LoadAndRunAction, which calls an action at runtime. LoadAndRunAction can be called as a function, and if the called actions returns a value via ExitActionIteration, it returns that value.
Yet another "beware" hint: ExitActionIteration really requires its arguments to be enclosed in brackets, even though it is a Sub (or at least called as a Sub). I suspect this is because it is not a real Sub or Function, but a special statement "patched into" the MS VBScript engine in some exotic way.
Bear with me here, ok!!
We use SMO a lot to do all kinds of things, including to check for the presence of particular stored procedures in the database. So we have a method in our data access class called HasProc, which returns a boolean. It's in a part of the application that hasn't been changed for over a year, possibly two years.
Lately, it's been taking ages (10s) to return a value, and I've been trying to pin down why.
It turns out that even defining the variable that will hold the SMO Server (not instantiating it, just defining it) causes a 10s delay in the code arriving into the function.
Here's the relevant bit of the code, which just returns True now, for clarity:
Public Function HasProc(ByVal storedProcName As String) As Boolean
Dim s As Microsoft.SqlServer.Management.Smo.Server
Return True
End Function
In Visual Studio 12, stepping through the code using F11, the 10 second delay happens before the code highlight arrives at Public Function etc...
If I comment out the Dim statement, it all runs instantly.
Even more weirdly, if I disable my ethernet adaptor, the delay does not occur.
This is reproducible across three computers. I'm using VS2012, and SMO v11, to which we recently upgraded in order to support SQL Server 2012.
The other thing is that the delay happens even if the Return True statement is before, rather than after the Dim statement.
Any ideas?
This would happen if the static initializer for that class performs network IO (which is generally a bad idea).
If you pause the debugger during the delay, you can find out exactly what it's doing.
I have a video tag with events.
For example, I have code such as:
myPlayer = document.getElementById("player");
myPlayer.onended=reachedEnd();
myPlayer.onpause = pauseEvent();
myPlayer.onplay = resumePlayer();
The problem is, that the event functions run immediately, I doubt they run when they are supposed to, but they certainly run when they are defined.
what am I doing wrong? (I did do an alert of 'myPlayer', and it is a video object, so that part is correct).
The parentheses next to the function names are causing the functions to run immediately. Instead, you want to refer to the functions like variables, passing references to them to the events. Instead, 'onended' etc. get set to the values returned by those functions, which is presumably undefined, so nothing happens when those events finally do occur.
Just get rid of the parentheses and you should be fine.
I am trying to populate the infoobject 0LOGSYS in a DSO when a load from a datasource occurs. The idea being that you could tell what sourcesystem the data was loaded from that is needed for a certain requirement. As of now I have a routine set up on a transformation rule for 0LOGSYS. No syntax errors, everything runs during the load, but no data is populated. Tried to debug but for some reason my BREAKPOINT is not getting picked up.
Here is the code that I have placed in the routine. Also, I am trying to do this without assigning any source field so maybe that is causing an issue. Not sure though.
TYPE-POOLS: RSSM.
Data: G_S_MINFO TYPE RSSM_S_MINFO.
CALL FUNCTION 'RSDG_ID_GET_FROM_LOGSYS'
EXPORTING
i_source_system = G_S_MINFO-LOGSYS
IMPORTING
e_soursysid = RESULT
EXCEPTIONS
id_not_found = 1.
Solved this a different way. There are runtime attributes that can be pulled from any request via the methods of "if_rsbk_request_admintab_view" which is instanciated automatically at the beginning of each transformation routine. Here is the code that I put in the routine.
*declaring a local variable like the result type LOGSYS
Data: lvSource like RESULT.
*runs a method to get the source system from the runtime attributes of
*the request
*"p_r_request" is an instance of "if_rsbk_request_admintab_view" which
*has many different methods for runtime attributes
lvSource = p_r_request->GET_LOGSYS( ).
RESULT = lvSource.
If this is the complete source code, it's not surprising that nothing is returned. You declare a new structured variable named G_S_MINFO, don't assign any value to it and return its contents. Unless you deleted the steps from your code sample that are supposed to fill the variable with values, it would be a grave bug if anything else than an initial value was returned.
EDIT: Even with the updated code, I still doubt this will work. Now you pass G_S_MINFO-LOGSYS to a function module that supposedly looks up some system ID without initializing it. Garbage in, garbage out. Or in this case, initial value in, initial value out.
I have a simple sql query in my Execute sql task in ssis package,
SELECT MAX(binindex)
FROM dbo.myTable
I need to store this maximum index into a variable and then pass it to Script Task and display it,
I already declared a package variable, the package compiles, however it shows -1 every time, I don't know what I'm doing wrong, any help will be appreciated!
public void Main(){
//TODO: Add your code here
Dts.TaskResult = (int)ScriptResults.Success;
MessageBox.Show(Dts.Variables["User::BININDEX"].Value.ToString());
}
The good news, is that you are doing everything correctly as far as I can see. I recreated your package and I get the expected value from my query.
I can also induce your situation - the correct value is returned from my query but my package produces an "incorrect result."
The problem, I hope, is that you have two BININDEX variables defined at different scopes. My original assumption was the Package scoped one contained a value of -1 and you had a variable scoped to the "Execute SQL Task" with the same name. The default behaviour is a variable is created scoped to the object that currently has focus. This changes in the 2012 release of SQL Server by the way.
As your picture shows a design-time value of 123 for the package scoped variable, the possibility also exists that you have a variable defined on the Script Task with the same name of BININDEX. The local variable would override the globally scoped variable
Click on your Script Task and hopefully you'll see a BININDEX defined there like the above. Otherwise, I think the problem is somewhere in your package, you have conflicting BININDEX variables. You can try slogging through the Package Explorer looking for an instance where you have two variables with the same name listed.
I need to leave but if none of that is the case, add a PostExecute breakpoint on the Execute SQL Task and look at your Locals window (not Variables as that only reflects Design-time values). Expand Variables and you should be able to see the value of BININDEX. Is it correct there?