DSXchange

It is only valid for Parallel jobs, from what I recall.

Of course it will always read all of the records, or at least attempt to based on your metadata. They will then 'come into' the Transformer stage but because of the constraint will not.. 'leave'.

Datastage server is on Unix and SMTP server is on Windows NT Operating system. Is there any software I have to install to get rid of this warning message ????? Talk to your UNIX Admin and/or a Network person. Explain the problem, show them the messages you posted, one or both should be able to help...

Note - they didn't "drop any Primary Keys' on the table, how could they? They stopped marking them as Key columns - big difference, and why the PK violation is still being thrown. I suggested a new post be constructed to finish working this, that obviously isn't going to happen. Can we stop posting ...

I don't really understand why this is such a problem or how we got to three pages. These are standard 'issues' you'd have to deal with in any database or even a 'key index' file system on any given day. Let's see if we can cut through the confusion and get to the bottom of this. There are not 'four...

Nope.

Whomever wrote it needs to fix it for you. And you are not 'executing' it (like you would in a job) you are 'Testing' it from the Manager... can make a difference.

You need to talk to Walter, see if you can drop the '2B' part and keep your history.

Why all the concentration on getting a Windows command? The post is marked as UNIX and the command is a UNIX command, so more than likely the 'NT' is the problem... in addition to what you posted regarding the syntax. So, how about: cmd = "mv /ss/ppff" : FileNameSuffix : ".txt /dd/ppf...

RTIclass?

Do we need to connect to oracle inorder to get in connected with ERP APPLICATIONS which resides on ORACLE. Yes, of course. And you can use ODBC, or a native connection using OCI or through an 'API' like process the PACKS that Vincent mentions would leverage. But you still, one way or another, need ...

Sorry - it's just a Pet Peeve of mine. I see way too many problems from a constant use of User-Defined SQL for no good reason. Mostly what I hear is it is 'easier' because it can be pasted from your query tool of choice. That or 'it makes it easier to read'. The perils of that approach are legion. A...

Guys - that field isn't required on a UNIX server and is not used in the dssendmail_template.txt file. Leave it empty.

[waves]

Of course. And why the fascination with User Defined SQL peoples? Nothing about using a parameter in a where clause requires user defined sql.