[b]shall we use the peek stage as a target[/b]

[fareeda_b]

shall we use the peek stage as a target

[ray.wurlod]

If you like. It's a good technique when incrementally developing a job. The Peek stage will eat all the rows you send to it, and send a sample of them to events in the job log.

[fareeda_b]

not getting exactly.

[ray.wurlod]

The Peek stage is intended to capture a sample of rows. If used as a target with no output link, all it can do is to capture that sample. It will write those few records into entries in the job log.

[juliank]

not getting exactly.

There isn't really antyhing that needs to be added to Ray's posts, but let me try from a newbie perspective...

I just started using DataStage and finding the Peek stage very helpfull when developing jobs in steps. Say, if you start from left and don't know what will be exactly to the right, just use a Peek stage and the data will get 'dumped' into it. Then add more, and you can still continue to utilize the Peek stage until at some point you will replace it with the actual target, or targets if you use several Peek stages. It is only a development 'utility' and you don't need to worry about columns/datatypes or anything like that. You can check what was 'dumped' in a Director log.

[eostic]

It works well, although I prefer to use a DataSet instead. I like staying always in the Designer and using view data....but it (Peek) is nice, and easy to "drop in" to the job anywhere.

Ernie

[ArndW]

I prefer the "view data" of a dataset over a peek, but will use a peek stage when I want to view interim data, i.e. when the peek stage needs to be put into the processing stream and has both an input and an output.

[ray.wurlod]

While still developing I prefer a sequential file stage if I need View Data capability - they're easier to dispose of afterwards.

As a stub I often use a Copy stage with no outputs - it eats rows beautifully and makes zero copies of them.