DSXchange

So your DataSet schema does not contain a column called "ARR_CLUS_ID" yet your job definition for the same DataSet refers to this column.

But does the schema in the DataSet match your definitions in the job? And can you view the data in the Data Set Management utility?

Sundar,

the warning is telling you that at least one record and more likely all 81 missing rows are being dropped because they have a NULL value and your target column does not allow nulls.

How have you checked this? The only reliable methods are to use the Tools -> Data Set Management or by calling the command line orchadmin program. This will show you the schema of the dataset and you need to compare that with your declared schema in the DataStage job.

Would it be possible to do a quick server job to just load a couple of rows with some value in this column? This might produce a better error message or might work but will also serve to narrow down the error.

Nic,
what is the column name you are using, and have you gone into the "edit row" attributes to ensure that you don't have some sort of a setting there that you aren't aware of?

Can you just add a PIC X(001). to your column definition? Or is your picture of the data larger than the actual data?

lol - I know that feeling; I'll retract my comment.

Nevertheless, without investing in expensive 3rd party ODBC software your route is the most viable option.

...anrd always says he wont reply to URGENT and always provides the solution...lol.. I only do that when it is a really easy answer that you could get by using GOOGLE and I would feel like a cad for not answering :D p.s. Shree, if you read the original question you will see that the poster wanted t...

Yes to both questions. In the user-defined SQL you can use job parameters by enclosing them in # signs, i.e. a select such as "SELECT (first,last,dob) FROM #Schema#.#TableName#". When using the parameters in a transform stage the # marks are not required. Best if you are unsure to use the drop-down ...

Ray has already pointed out the main difficulties involved. The DataStage BASIC language does offer a method to read a sequential file by using direct positioning, so you could code a routine or program to read the next {n} bytes of a file, then parse the contents to decide which record type you hav...

The local files are, as Ray has shown, easily found and tracked using the STAT.FILE contents. The difficulty lies in locating all those hashed files that aren't referenced in any VOC when given just a device and inode. I thought that some of the denizens here might be interested in how to get from a...

Many of the file related internal displays and commands, notably the LIST.READU command, will show a DataStage user as having a Device and Inode open for a hashed file. Question: How do you find out what physical file is actually open? Answer: You need to take several steps in order to get the answe...

When you schedule a job from the director in a default UNIX environment it will use "cron"; DataStage does not have it's own scheduler. Once you've scheduled the job, look at your crontab to see what the actual command is that is being issued. Also remember that this process needs to have the dsenv ...

If the records are of variable length then there needs to be some character or characters that denotes the end-of-line, even when transferring the data in binary mode.

Does each record type have a fixed width, but each record type has a potentially different length from the others?