DSXchange

Whoops, right when I clicked on Submit I see we are talking about a Server job, so... I would wager your fields are not properly quote delimited and you in fact have an invalid csv file. Can you post an actual example or two so we can see?

PX is notorious for having problems with commas in the data of a csv file, even if the fields are quote delimited. You may find you'll need to use a Server job for this task as it can handle them just fine... assuming they are properly quoted: xxx,"3,890,454",xxx,

Fairly simple in a Server routine: Loop through the string using Field() with ";" as the delimiter, ..Use Index() to see if "VARIABLE=" is in the token, ....If yes, Field() again with "=" as the delimiterm take 2nd field, ..Stop when first non-null value found or you ru...

Post the syntax you tried. Also, real examples of data you want and data you don't want to match. Include some of the troublesome ones, too, the ones that got through that shouldn't have.

Tried what? Forget adding the BASIC Transformer and show us what you are trying to do instead.

As noted, let us know what you are trying to do and we'll see if we can help with what you need to accomplish it.

Their posts indicate quite a difference in environments, the biggest being the fact that the 7.x environment was a grid environment while the 8.x one is not grid enabled.

:!: Please repost this in the proper forum, this one is for discussing potential FAQ topics. Normally, the advice would be to put it in the Server or PX forums based on the job type in question but since this is more generic than that, please put it in the General forum. Edited to add: And I see tha...

How many processing nodes are you using with your jobs?

I'm going to disagree with your "longer" comment unless you specifically mean in a recovery situation where it may take longer because you have to load "everything" again and you could be waiting for the rollback to complete. True, but I'll take that over any kind of a "manu...

If at all possible, I prefer an "all or nothing" style of load where commits are only done once at the end. That means a restart is simply a restart and something that can be handled at the job control level.

There is no "automatic" functionality if you are talking about restarts at the job level, i.e. inside a job. Sequence jobs can automate restarts between jobs but I suspect that's not what you mean.

I've got no direct experience with it either, but do want to ask - this "64bit architecture", are you just talking O/S (meaning DataStage is still 32bit) or is your version of DataStage now 64bit as well?

And sometimes you'll wait 20 or 30 minutes and sometimes you'll wait forever. One really needs to learn to check as Arnd noted and only restart once all ports clear.

Basically asking if the problem is consistent or not. In other words, do the exact same connections fail each time or do the failed ones change with each run? If it is the latter, then I'd be checking with your DBA and/or SysAdmin to see if you are having resource issues.