Records not updating in Script Component

I am seeing a strange behavior in a script component that I can't figure out.

Basically, there is a field in my script that checks to see if a string field is length of 1. If it is, it updates the field with some value. The strange behavior is that it picks up some of the rows but not others.

If Row.FieldValue.Length = 1 Then

Row.FieldValue= "Some Value"

End If

I've tried variations such as:
If left(Row.FieldValue.,1) = "-" Then

Row.FieldValue= "Some Value"

End If

But I get the same results. Any Ideas?Does [Field] need to be trimmed? Might some data contain trailing white spaces?|||

No, I've tried every combination of Trim, left, equals etc...that I can think of. The funny thing is that it picks up some of the fields and misses others.

Very puzzling. I was hoping to hear of some rare condition on this board that sounds similar to this, but I have yet to hear of any similar situations.

The code that I am talking about is incredibly simple, as shown in my previous post.

|||What happens when [Field] is null?|||

You could fire some debug iformation to help you. Something like this maybe:

Me.ComponentMetadata.FireInformation(,,Row.FieldValue.ToString() + " - " + Row.FieldValue.Length.ToString(), ....

-Jamie

|||

Thanks, that did it. I am relatively new to SSIS, never really delved into the debug information before.

that is very helpful.

|||

KML67 wrote:

Thanks, that did it. I am relatively new to SSIS, never really delved into the debug information before.

that is very helpful.

Great! But what solved your issue?|||

Basically, matching the string by length, equal, explicit match was working fine all along.

There was some logic that followed this string test that was providing the error. The error was very subtle, so it did not always produce the same value for the same input (depending on multiple variables), but at quick glance (watching the data flow into and out of the component with dataviewers) it looked as like there was an inconsistency in the component itself.

Jamie's post was very helpful, I am new to SSIS and wasn't familiar with the fireInformation method. That allowed me to solve it in a second.

Thanks for the tips, this board is a great asset.

Record locking...

Hi Experts,
Here's the scenario of the case...
User1 does a retrieve of information, with the intention of updating it
later. At the same time, User2 does a retrieve of information, with the
intention of updating it later. User1 updates some of the row on the web
server, and then calls an update stored procedure.Then user2 updates some of
the row on the web server, and then calls an update stored procedure.
Some of user1s updates are lost because user2 had "stale" data.
So what a lot of applications do is to implement explicit locking, so that
when user1 did the retrieve, he had to say "I want to lock it cuz Im gonna
update it later". The rule is in that case that a locked record cannot also
be locked by someone else
and update can only be called if the record was locked by that user.
We can of course add a column to every table that has to support this
"locking", but I was wondering if SQL Serversystems support some kind of
"lock this record please"?Here's an old archive on this type of issue:
http://tinyurl.com/5qevd
-oj
"Lia" <Lia@.discussions.microsoft.com> wrote in message
news:9A1DD01A-FA17-4785-B6F6-3869907C9DE9@.microsoft.com...
> Hi Experts,
> Here's the scenario of the case...
> User1 does a retrieve of information, with the intention of updating it
> later. At the same time, User2 does a retrieve of information, with the
> intention of updating it later. User1 updates some of the row on the web
> server, and then calls an update stored procedure.Then user2 updates some
> of
> the row on the web server, and then calls an update stored procedure.
> Some of user1s updates are lost because user2 had "stale" data.
> So what a lot of applications do is to implement explicit locking, so that
> when user1 did the retrieve, he had to say "I want to lock it cuz Im gonna
> update it later". The rule is in that case that a locked record cannot
> also
> be locked by someone else
> and update can only be called if the record was locked by that user.
> We can of course add a column to every table that has to support this
> "locking", but I was wondering if SQL Serversystems support some kind of
> "lock this record please"?|||Hi Experts,
What is usually the system? Is it the person who updates gets the priority
or the person who retrieves (for update) gets a priority.
I have been debating on this for some time and after reading a few books i
got the impression that LOCKING records was the practice in the olden days
and in the current situation ( adLockOptimistic ) the person who clicks
update first get a priority and the other person gets an ERROR! Which can be
trapped using ON Error GOTO statement
Please clarify and help me resolve this issue.
Thanks
Manish
"oj" wrote:

> Here's an old archive on this type of issue:
> http://tinyurl.com/5qevd
>
> --
> -oj
>
> "Lia" <Lia@.discussions.microsoft.com> wrote in message
> news:9A1DD01A-FA17-4785-B6F6-3869907C9DE9@.microsoft.com...
>
>|||Hi Manish,
Thanks for your reply on my post. :-) The system will supposed to give the
priority to person who retrieves(for update) in such a way that upon
retrieving, the record will be locked. The lock will then be released after
updating the record or canceling the transaction. And if the other person
select the same record that intend to update it also, message will be given
to inform the person that the record can only be viewed and cannot be update
d
because it is locked for update by another user.
Your suggestions and comments will be highly appreciated.
Thanks,
Lia
"Manish Sawjiani" wrote:
> Hi Experts,
> What is usually the system? Is it the person who updates gets the priority
> or the person who retrieves (for update) gets a priority.
> I have been debating on this for some time and after reading a few books i
> got the impression that LOCKING records was the practice in the olden days
> and in the current situation ( adLockOptimistic ) the person who clicks
> update first get a priority and the other person gets an ERROR! Which can
be
> trapped using ON Error GOTO statement
> Please clarify and help me resolve this issue.
> Thanks
> Manish
> "oj" wrote:
>