PF Usage

I have a SQL server 2005 box with 8 GB physical memory. The windows task
manager reports 7.4G PF Usage. Is this accurate?Hello,
It should be correct. But use the performance monitor to measure the correct
usage. Take a look int the below URL:-
http://msdn2.microsoft.com/en-us/library/ms176018.aspx
Thanks
Hari
"morphius" <morphius@.discussions.microsoft.com> wrote in message
news:55174532-F7F0-4EEC-8427-81C271DFF935@.microsoft.com...
>I have a SQL server 2005 box with 8 GB physical memory. The windows task
> manaer reports 7.4G PF Usage. Is this accurate?

Persisting Package Variables

I was able to write successfully a Script Task to set the values of several package variables. But when the execution completes, the variables still contain values which were specified by default.

What I want is a method of persisting the values assigned to a variable through a script. I believe this was possible in DTS

The variable is not saved, because you have not saved the package. There is no way to do this really, so for anything you wish to persist between package executions you should store externally. If you want to see the value of variables during execution then use a breakpoint and drag the variables to the watch window. You do not see the value in BIDS because the package loaded in BIDS is not the same instance as that being executed. When you execute the package is saved, and a copy loaded into memory of the execution host. The copy in BIDS remains where it is as the debug copy.

In DTS when executing through Enterprise Manager it was the same copy, so you could see the value of variables post execution. The values were still not saved though, it was just a factor of you having only one instance of the package in memory. If you were executing through DTSRUN and variables changed they did not get persisted, as the package was not saved. The changed copy was thrown away once execution completed.

Persistant VariableName error in Row Count task

I am getting this error:

The variable "MyVariable" specified by VariableName property is not a valid variable. Need a valid variable name to write to.

This is my scenario:

I had a Row Count task on a data flow that was writing to a locally scoped variable (called MyVariable for this example.)

I needed to access the value of this variable at the Control Flow (global scope), so I deleted it and recreated it at that level.

My new variable has the same name as the old variable, just different scope.

Now I get this error every time I run the package.

BUT WAIT THERE'S MORE!

I have another Row Count step in the same data flow that is presently writing to a globally scoped variable called "ErrorRows."

If I change this step to write to MyVariable it works fine. If I change my other step to use ErrorRows, it works fine. If I change them back I get the error again.

I have tried deleting and recreating the step, and the variable, and using different names for them. Something is very jiggy with this variable!!

Variables names are case sensitives; make sure you are using the proper casing and that the variable is defined in the right scope.

|||

Can you share the package?

|||

I have discovered that the problem lies not in the Row Count task, but somehow in the Script task that immediately follows it.

I still haven't been able to isolate the issue, but for some reason the error is showing as related to the Row Count task.

(That is why I had been unable to shake the error despite deleting and re-creating the task.)

The script is unexceptional. It is simply incrementing a counter to generate a new row id. For some reason it is using the row count, but since the row count in my present tests is 0 the script should not be executing at all, and the error is not an execution error.

In answer to the suggestion above, the yes the case of the variable name is correct. The steps are all passing validation (no little red circles with x's in them) but failing at runtime.

Dylan.

|||Do you have the variable you are referencing in the Row Count marked as read or read/write in the script component? If so, the issue may be that the variable is locked when the Row Count tries to access it.|||

I have removed the variable altogether from the script step, as I realised on reflection that it really wasn't necessary there.

This really was confounding behaviour, however. The way in which the row count step was flagged in error made it tricky to diagnose what was wrong, so I hope that this thread helps out someone else.

I was unable to determine why the script step was having trouble with the variable. I suspect that the engine was trying to run both count and script at the same time, and there was contention for the variable. The variable was read-only in the script step, however.

Anyway, now onto the next issue...

Persistant VariableName error in Row Count task

I am getting this error:

The variable "MyVariable" specified by VariableName property is not a valid variable. Need a valid variable name to write to.

This is my scenario:

I had a Row Count task on a data flow that was writing to a locally scoped variable (called MyVariable for this example.)

I needed to access the value of this variable at the Control Flow (global scope), so I deleted it and recreated it at that level.

My new variable has the same name as the old variable, just different scope.

Now I get this error every time I run the package.

BUT WAIT THERE'S MORE!

I have another Row Count step in the same data flow that is presently writing to a globally scoped variable called "ErrorRows."

If I change this step to write to MyVariable it works fine. If I change my other step to use ErrorRows, it works fine. If I change them back I get the error again.

I have tried deleting and recreating the step, and the variable, and using different names for them. Something is very jiggy with this variable!!

Variables names are case sensitives; make sure you are using the proper casing and that the variable is defined in the right scope.

|||

Can you share the package?

|||

I have discovered that the problem lies not in the Row Count task, but somehow in the Script task that immediately follows it.

I still haven't been able to isolate the issue, but for some reason the error is showing as related to the Row Count task.

(That is why I had been unable to shake the error despite deleting and re-creating the task.)

The script is unexceptional. It is simply incrementing a counter to generate a new row id. For some reason it is using the row count, but since the row count in my present tests is 0 the script should not be executing at all, and the error is not an execution error.

In answer to the suggestion above, the yes the case of the variable name is correct. The steps are all passing validation (no little red circles with x's in them) but failing at runtime.

Dylan.

|||Do you have the variable you are referencing in the Row Count marked as read or read/write in the script component? If so, the issue may be that the variable is locked when the Row Count tries to access it.|||

I have removed the variable altogether from the script step, as I realised on reflection that it really wasn't necessary there.

This really was confounding behaviour, however. The way in which the row count step was flagged in error made it tricky to diagnose what was wrong, so I hope that this thread helps out someone else.

I was unable to determine why the script step was having trouble with the variable. I suspect that the engine was trying to run both count and script at the same time, and there was contention for the variable. The variable was read-only in the script step, however.

Anyway, now onto the next issue...