DSXchange

I defer that title to Ray... err, I mean Mr Wurlod.

In other words, a non-zero record count. Lots of posts on this subject lately. You can do it all in a Routine or a shell script, whichever you feel more comfortable with. Search for topics discussing things like DSGetLinkInfo with the 'row count' info-type argument to check the number of records tha...

No, no, no... read the documentation on what exactly the Operator role allows. An Operator can only see Released jobs - something basically no-one does anymore. In other words, the advent of Version Control completely nerfed the Operator role. Give them access to the project as a Developer but make ...

We were trying to use "Update existing rows and insert new rows" , which end up in performance issue. That's typically the slowest approach you could have taken. Define what 'costing too much' means in the 'split inserts and updates' scenario. What is your mixture of inserts versus updates, percent...

How does your job 'know' these things? If it knows them, go ahead and use that knowledge in the Sequential File stage. What you should be doing is parameterizing both pieces and use those parameters in the stage. Forget about all this 'before routine sets parameter values in running job' or seeking ...

Pretty much exactly what it says: you have a stage in the job that requires a User ID - typically a Database stage - and you haven't supplied one. Shouldn't be all that hard to track down...

Odd... just the one? Any idea if there is any funky in it? Try putting the variable in the body of the email rather than the subject to check it out...

Which exact 7.x version, btw?

I think it's pretty obvious that they are.

You are trying to create an xsd rather than xml from the stage?? I really don't think that is possible.

Detail Suppression. Run the query with and without and you shall see, my young Padawan.

Have you double-checked with your admin that it is actually scheduled under the id you think it is? That's always been my understanding as to how both 'at' and 'cron' work - by userid - and that the userids must match for anything schedule related to show up in the Director. If you still think there...

Coming back to this as we just ran into this message on a new Server install. COmpounding the trouble-shooting was the fact that this new HP-UX based server was installed with 7.5.2 of DataStage where all others are still on 7.5.1A. Testing and all that rot. One particular hashed file would not crea...

Scheduling information is retrieved by userid, so it must have been scheduled under a different user than you are currently logged in with.

As Ken notes, when working with large numbers like that you need to stick with the 'string math' functions. SDIV is one, there are equivalents for the others as well.

One-offs need 'at' permissions granted, not cron.