Showing posts with label task. Show all posts
Showing posts with label task. Show all posts

Thursday, March 22, 2012

Bug? Transfer SQL Server Objects Task - error when copying Views

I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:

Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)

I know the view exists at the source because:

A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source

Somehow the views are not transferring. Anyone have any ideas?

I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||

So has this been fixed? I'm getting the same error:

[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.

I know the referenced table exists at the source.

|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||

I've use the same way.

This Task checks the Objects and Columns casesensitive.

So all Objects and Columns must be identically named.

|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?sql

Bug? Transfer SQL Server Objects Task - error when copying Views

I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:

Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)

I know the view exists at the source because:

A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source

Somehow the views are not transferring. Anyone have any ideas?

I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||

So has this been fixed? I'm getting the same error:

[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.

I know the referenced table exists at the source.

|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||

I've use the same way.

This Task checks the Objects and Columns casesensitive.

So all Objects and Columns must be identically named.

|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?

Bug? Transfer SQL Server Objects Task - error when copying Views

I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:

Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)

I know the view exists at the source because:

A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source

Somehow the views are not transferring. Anyone have any ideas?

I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||

So has this been fixed? I'm getting the same error:

[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.

I know the referenced table exists at the source.

|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||

I've use the same way.

This Task checks the Objects and Columns casesensitive.

So all Objects and Columns must be identically named.

|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?

Bug? Transfer SQL Server Objects Task - error when copying Views

I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:

Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)

I know the view exists at the source because:

A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source

Somehow the views are not transferring. Anyone have any ideas?

I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||

So has this been fixed? I'm getting the same error:

[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.

I know the referenced table exists at the source.

|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||

I've use the same way.

This Task checks the Objects and Columns casesensitive.

So all Objects and Columns must be identically named.

|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?

Tuesday, March 20, 2012

Bug: Expression on Disable property doesn''t have desired effect

[Microsoft follow-up]

Hello,

I think I've found a bug.

I have an expression set on the 'Disable' property of a data-flow task. When the expression evaluates to true the data-flow still executes. That seems wrong to me.

I ahve a demo package here: http://folders.live.com/self.aspx/VQ9oHa1TJjc/Public/SSIS%20Stuff/ExamplePackages/20070717%20Expression%20on%20Disable%20property%20has%20no%20effect/Package1.zip

Please reply letting me know whether this is indeed a bug or not.

I'm on SP1 by the way.

Regards

Jamie

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

|||

Phil Brammer wrote:

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

Well that's not intuitive at all. And it also wouldn't explain why this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=465533&SiteID=1 would work.

Hopefully someone from the SSIS team replies ASAP.

-Jamie

|||

The following configuration will disable the data flow, using your example.

Code Snippet

<?xml version="1.0"?>

<DTSConfiguration>

<DTSConfigurationHeading>

<DTSConfigurationFileInfo GeneratedBy="CT\jtbx" GeneratedFromPackageName="DisableProperty" GeneratedFromPackageID="{DDA8184A-42AF-414A-B01C-CB3FCCB8988D}" GeneratedDate="7/17/2007 7:50:43 PM"/>

</DTSConfigurationHeading>

<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Variable].Properties[Value]" ValueType="Int32">

<ConfiguredValue>1</ConfiguredValue>

</Configuration>

</DTSConfiguration>

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

Since package configuration occurs at load time, configuration of properties will affect the container's Disable property, either directly or via an expression, while the script task sets the expression-participating variable at execution time, and is thus too late.

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

|||

jaegd wrote:

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

If that's true then I'd like to understand the rationale behind it because that behaviour is totally different from any other container property.

jaegd wrote:

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

It uses a configuration to set the value but that is irrelevant in the context of this thread. I'm talking about how an expression on the Disable property is not being evaluated properly.

Thanks for the reply jaegd but I still want a response from Microsoft.

-Jamie

|||

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT

|||

Ovidiu Burlacu wrote:

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT


Thanks Ovidiu. I look forward to the reply.

|||

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

|||

Ovidiu Burlacu wrote:

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

From Jamie Thomson:
[I've asked Phil to post this for me as I am currently locked out of the forums due to some bug]

Thanks Ovidiu. I have posted the bug here: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=290209

Interestingly, I found out that this has been raised before back in 2005 (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125166) and Sergei Ivanov closed it as "by design". I don't agree and clearly you, Ovidiu, don't either. Which I'm glad about.

- Jamie

Bug: Expression on Disable property doesn't have desired effect

[Microsoft follow-up]

Hello,

I think I've found a bug.

I have an expression set on the 'Disable' property of a data-flow task. When the expression evaluates to true the data-flow still executes. That seems wrong to me.

I ahve a demo package here: http://folders.live.com/self.aspx/VQ9oHa1TJjc/Public/SSIS%20Stuff/ExamplePackages/20070717%20Expression%20on%20Disable%20property%20has%20no%20effect/Package1.zip

Please reply letting me know whether this is indeed a bug or not.

I'm on SP1 by the way.

Regards

Jamie

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

|||

Phil Brammer wrote:

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

Well that's not intuitive at all. And it also wouldn't explain why this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=465533&SiteID=1 would work.

Hopefully someone from the SSIS team replies ASAP.

-Jamie

|||

The following configuration will disable the data flow, using your example.

Code Snippet

<?xml version="1.0"?>

<DTSConfiguration>

<DTSConfigurationHeading>

<DTSConfigurationFileInfo GeneratedBy="CT\jtbx" GeneratedFromPackageName="DisableProperty" GeneratedFromPackageID="{DDA8184A-42AF-414A-B01C-CB3FCCB8988D}" GeneratedDate="7/17/2007 7:50:43 PM"/>

</DTSConfigurationHeading>

<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Variable].Properties[Value]" ValueType="Int32">

<ConfiguredValue>1</ConfiguredValue>

</Configuration>

</DTSConfiguration>

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

Since package configuration occurs at load time, configuration of properties will affect the container's Disable property, either directly or via an expression, while the script task sets the expression-participating variable at execution time, and is thus too late.

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

|||

jaegd wrote:

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

If that's true then I'd like to understand the rationale behind it because that behaviour is totally different from any other container property.

jaegd wrote:

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

It uses a configuration to set the value but that is irrelevant in the context of this thread. I'm talking about how an expression on the Disable property is not being evaluated properly.

Thanks for the reply jaegd but I still want a response from Microsoft.

-Jamie

|||

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT

|||

Ovidiu Burlacu wrote:

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT


Thanks Ovidiu. I look forward to the reply.

|||

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

|||

Ovidiu Burlacu wrote:

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

From Jamie Thomson:
[I've asked Phil to post this for me as I am currently locked out of the forums due to some bug]

Thanks Ovidiu. I have posted the bug here: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=290209

Interestingly, I found out that this has been raised before back in 2005 (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125166) and Sergei Ivanov closed it as "by design". I don't agree and clearly you, Ovidiu, don't either. Which I'm glad about.

- Jamiesql

Monday, March 19, 2012

BUG REPORT: ReadWriteVariables different between Script Task and Script Component

I have just spent two hours banging my head off the wall to figure this one out... wondering if I had a problem with variable scope or something...

I had a Script Task which was taking a few package level variables to use in the script.

So I put the list of variables in the ReadWriteVariables property.

Specified them like this:

"User::FileBeingProcessed, User::FileSource"

And all was well....

Then later on decided to use the same set of variables in a Script Component contained in a Data Flow.

And kept kept getting a "..variable not found.." error dialog when I clicked on Design Script.

Finally the solution came to me: Spaces in the list of variables !

In a script task you can have a space after a comma in the list... but in a script component you CAN'T !!

So what works in a Script Task is :

Task : "User::FileBeingProcessed, User::FileSource"

But that will not work in a Script Component...

See the difference?:

Task :"User::FileBeingProcessed, User::FileSource"
Component:"User::FileBeingProcessed,User::FileSource"

I know the BOL says to use a comma separated list.. but.. some consistency would be nice...

PJ

I agree..that's a bit...err...cra@.p!

I always thought both used the syntax without a space in there and hence that what I always use - and hence I never have a problem with it.

Bug it! http://lab.msdn.microsoft.com/productfeedback/default.aspx

-Jamie

|||

Oh yeah, if you worked without the spaces you'd never see the problem... its just if you're an awkward fecker like me... heh heh...

Very misleading tho.. I was thrashing around for ages worried about scope (since the Script component is only down inside a data flow) and then applying service packs.. etc...

Still.. yer eventually glad just to find out yer not going crazy...

heh,

PJ

Bug Report: Expressions not deleted

I've noticed that if you create a data flow task (such as a DataReader source) and then bind an expression to it, if you rename or delete the task the expressions bound to the task will disappear but still be in the DTSX itself. So, if your expressions stop parsing (if you remove a variable, etc.) you will get errors for these expressions which you thought should have been removed. The workaround is to re-add the tasks with the old names and go delete the expressions from the expression list.
I suggest you raise a bug at http://lab.msdn.microsoft.com/ProductFeedback|||I could reproduce this problem and filed a bug.

Sunday, March 11, 2012

Bug in Task

Hi all,
I have a job that run 3 task. The first one do a backup, the second one copy those backup files from one drive to another drive, the third one supposed to delete the backup from the first drive. What is happening is as soon as the second task start the third task also start for some reason, it does not wait for all the backup files to be moved, so i end up with one backup file being copied on the second drive (locking the backup file) but all the other backup get deleted except for the lock file. Has anyone encounter the same problem? is there a way i can set up the third task not to start until the second is completed?

axel_2005 wrote:

Hi all,
I have a job that run 3 task. The first one do a backup, the second one copy those backup files from one drive to another drive, the third one supposed to delete the backup from the first drive. What is happening is as soon as the second task start the third task also start for some reason, it does not wait for all the backup files to be moved, so i end up with one backup file being copied on the second drive (locking the backup file) but all the other backup get deleted except for the lock file. Has anyone encounter the same problem? is there a way i can set up the third task not to start until the second is completed?

Do you have any precedence constraints (i.e. blue, red or green lines) between your tasks?

-Jamie

|||the tasks are link by the green arrow|||That's weird. Have you messed with the precedence constraints? When you draw a green arrow between task, by default a 'upon success' precedence is created. Just to make sure, check the options of the precedence constrains by double clicking the green arrow between the 2nd a 3rd task.|||I found a work around. Apparently when the task copy files from one place to another, it somehow return a success even though it did not copy all the files (i would say as soon as it copy the first file) so I removed the maintenance clean up and added another step to delete the files in task 3, that way only when the first step is done it will go to the next step. Thanks for your help.

BUG in SSIS OLE DB Source Build Query

Can anyone help me with this ?


I am trying to extract data from oracle 9i server and
pushing it onto the SQL Server 2005 using Data Flow Task.
Details for OLE DB Source are :

OLE DB Source Editor Details:

OLE DB Connection Manager - Oracle Source

Data Access Mode - SQL Command

SQL Command Text -

SELECT EMPNO, EMPNAME, JOB, HIREDATE
FROM EMP_DETAILS
WHERE (HIREDATE > TRUNC(SYSDATE) - 1)

SSIS parses this query succesfully but when i build the query it shows query

SELECT EMPNO, EMPNAME, JOB, HIREDATE
FROM EMP_DETAILS
WHERE (HIREDATE > TRUNC("SYSDATE") - 1)


Please note :- SYSDATE IN " "

This query returns no Result Set.

Try using GETDATE() instead of SYSDATE, that is the Oracle function for returning the current date.|||Hi there,

i don't find any such function in oracle, getdate() is there in MS SQL Server.

Thanks.
|||

I don't think there is any. AFAIK Sysdate is the equivalent to GetDate() in Oracle. I am having the exact same problem as you using an OLE DB Source to access an Oracle DB - and it annoys me to no end that I cannot get the system date for comparison. If anyone else has a solution for this it would be much appreciated.

|||I am having the same issue in a similar situation... I change my query in the .xsd dataset to include a clause that references SYSDATE, but when VS tries to rebuild the code it ALWAYS adds the double-quotes around sysdate and it treats it as an identifier, which of course does not exist.

SELECT HZ.LOCATION_ID, HZ.DESCRIPTION, HZ.ADDRESS1, HZ.ADDRESS2
FROM AR.HZ_LOCATIONS HZ INNER JOIN
CSI.CSI_A_LOCATIONS CSI ON HZ.LOCATION_ID = CSI.LOCATION_ID
WHERE (NVL(TRUNC(CSI.ACTIVE_END_DATE), '01-JAN-4000') > TRUNC(SYSDATE))

Always becomes

SELECT HZ.LOCATION_ID, HZ.DESCRIPTION, HZ.ADDRESS1, HZ.ADDRESS2
FROM AR.HZ_LOCATIONS HZ INNER JOIN
CSI.CSI_A_LOCATIONS CSI ON HZ.LOCATION_ID = CSI.LOCATION_ID
WHERE (NVL(TRUNC(CSI.ACTIVE_END_DATE), '01-JAN-4000') > TRUNC("SYSDATE"))

Has anyone found a way to prevent VS from doing this?
|||Hi Anthony,

There is only one way around, Don't build the query !
In my application i am just parsing the query n its working fine.
you try to build the query n query builder will make sysdate famous by quoting it.

Thursday, February 16, 2012

Breakpoint doesn't work

I've got a breakpoint in a script task. The script task executes successfully but doesn't break.

Short and sweet this one. Anyone any idea why it might not?

-JamieHey Jamie, I believe I read somewhere in the pipe that breakpoints weren't going to work until the prod release...|||

JAson_scoobyjw wrote:

Hey Jamie, I believe I read somewhere in the pipe that breakpoints weren't going to work until the prod release...

Nah, I know this has worked in the past and I've read posts today from people that have had it working.

-Jamie|||We don't support breakpoints in script data flow component in this release.

The script task breakpoints should work, except when the package is executed using 64-bit runtime on x64 machines.

Jamie - are you using CTP 16? I remember in some older builds the script task breakpoints did not work if the PreCompile property of the task was true. I think it is fixed in CTP 16 (but it could be after CTP 16 - for RTM, not sure).|||

Michael Entin SSIS wrote:

We don't support breakpoints in script data flow component in this release.

The script task breakpoints should work, except when the package is executed using 64-bit runtime on x64 machines.

Jamie - are you using CTP 16? I remember in some older builds the script task breakpoints did not work if the PreCompile property of the task was true. I think it is fixed in CTP 16 (but it could be after CTP 16 - for RTM, not sure).

Hi Michael,
Yeah, I am using Sept CTP/IDW 16 and I do have PreCompile=TRUE.

The package is at the office and I am currently at home so I'll check this out (i.e. set PreCompile=FALSE) on monday.

-Jamie|||http://blogs.conchango.com/jamiethomson/archive/2005/10/15/2271.aspx|||I found that if you are in debug at a breakpoint on a looping bit of code. If you press F5 the code then continues and doesn't break on the break point again, even though the statement with the breakpoint is executed again.

I thought F5 ran the code and if a breakpoint is found it should stop?|||Is it true that breakpoints won't work in a script component?

I just wrote a script source component to reorder the columns in incoming CSV's based on the column names in the first row.

I set some break points to debug, but they get ignored every time I try to run it. My "precompile" flag is set to false per some earlier posts, but that doesn't seem to affect the issue.|||SSIS does not currently support breakpoints in script components.

You will need to put some logging information in your script component see my post http://www.sqljunkies.com/WebLog/simons/archive/2005/08/03/SSIS_Script_Component_Debugging.aspx