DSXchange

Server routines automatically return the value of their "Answer", do you have that set properly? After that, you just refer to the stage_label.$ReturnValue variable anywhere downstream from it.

You are reading too much into what I wrote. I never said the "entire repository". It's one thing to select information from the repository, it's another thing entirely to be inside modifying it. I'm not about to condone nor in any way enable that, the only time you should be in under the c...

Suggest you do an exact search for "Null string argument", this has already been asked and answered here.

Please pay attention to how your posts are marked - Server job questions should use a Job Type of Server, at the moment this post is a bit like Bilbo Baggins - there and back again. Whatever magic Ray does will remove the errant "moved" entry. Also please search before you post, more than ...

Found the article I was thinking of, you can find it in the Learning Center here. There's also a post here with some discussion and a link to another product's pdf on their dynamic file implementation, similar enough to be helpful here.

A hash value is computed for the key fields (thus the name) and that is used to store the value. I seem to recall a Ken Bland post here with all kinds of gory details about hashed files... and I'm sure Ray has a thing or two up his sleeve.

I'm curious which part of "it's not possible" is unclear.

Yes, the syntax is valid but only execute that if you want to (essentially) corrupt your repository.

So confirm for us the target field - does it show as VARCHAR2 50 BYTE or VARCHAR2 50 CHAR?

There's no hard-and-fast rule. To me, it would be fine to mark it as a Workaround for now but then come back with any resolution from Support, including none. If they give you a working solution, mark the post as Resolved.

Don't use a Sequential File stage to read XML, too many possible issues there. Follow Ernie's advice here instead.

muralidwhds wrote:Target field length is 50 Chars

Your database is using byte semantics and thus your target field length is 50 bytes long, not 50 characters. It won't fit, period. See if you can talk your DBA / Architect into switching semantics.

a.sarkar wrote:I think somewhere we need to document this limitation and the solution to this limitation.

We just did!

I have no idea off the top of my head what your issue might be but would say if it is "very urgent and has got lot of dependancy" that you contact your official support provider and let them know your system is down.

On a side note, what changed 2-3 days ago? Something obviously did.

No can do.

OK, straighten out something for us. You've posted in the PX forum but marked your post as 'Server', which one is it? And what does your job design look like, in particular which target stage are you using?