DSXchange

Adjacent to this warning in the log should be another one showing you the actual data in the row to which the ODBC driver objected. If you inspect the data you may be able to spot the offending value. There are apparently only two Date columns, so it should not be all that difficult to ascertain whi...

I've always done so ("doing it right"), since version 1.0, so I'm not the one to ask.

The messages are certainly being generated by the Row Splitter stage. It "believes" (if I may be anthropomorphic temporarily) that there are too many columns in the data. This can arise, for example, if there are instances of the delimiter characters used within the row splitter stage (specified on ...

Another thought - could it be that the table names exist in another schema as well as in ST? What happens if you use table name aliases (you can do this in the table names list and in the column derivations)? SELECT T1.ZIPCODE_ADR,T1.SALES_REP_IDN,T1.SAFETY_REP_IDN,T1.UPDATE_DATE,T1.CODE,T2.POLICY_U...

Well, that definitely appears to be unambiguous; every column name in the query is qualified with its table name. What SQL was reported in the DataStage log when you ran the job? Probably the event prior to the Oracle error.

You access Excel via ODBC. The ODBC standard (published by Microsoft) specifies that dates are in ISO 8601 format (YYYY-MM-DD) and that timestamps are in ISO 8601 format (YYYY-MM-DD HH:MM:SS). It is the ODBC driver that is reporting dates in this format. Because it is obliged to, because it follows ...

The DS_AUDIT table is publicly accessible. It's just not exposed in the DataStage clients, apart from DTM being displayed in Manager. From the Command window (Administrator client) or in the dssh environment on the server, execute this command to determine the column names. LIST.DICT DS_AUDIT To fin...

Can you post the actual generated SQL?

Did you do exactly the following? Addition='DSU.CalledSub' Call @Addition(Ans,10,12) Remember that user-written routines are catalogued with a "DSU." prefix to their name. It is the catalogue name that one must use in a CALL, whether using the indirect ("@") method or not. Ans = Subr(&qu...

None. About the only available strategy is to record (trace) what happens with the old version of the job design, to record (trace) what happens with the new version of the job design, and to compare these. This involves planning, and recording prior to making changes, which means that it's too diff...

It doesn't actually hang, but it does take a long time to retrieve even the most recent 100 records from RT_LOGnnn (because it uses a full table scan to determine which ones they are). The preventive measure is to resize the RT_LOGnnn file so that it uses 64-bit addressing internally. Make sure you ...

Officially there's no way to protect individual components. However, every object in the Repository has a READONLY property, which you can set to 'RO' (read-only) or 'NRO' (not read-only). Search the forum for the SQL you need to achieve this. Basically, you need to identify the particular objects, ...

You *could* use the OpenPath and Write technique you used earlier. Better is to use OpenSeq, perhaps WeofSeq to truncate or Seek to append, WriteSeq to write one line, and CloseSeq to close. Search for these in the forum, in on-line help, or in the DataStage BASIC manual. However, my intent with the...

A1. The only other way for BASIC subroutines is the Subr() function. A2. The methods are identical when implemented. A3. Transforms are not independent components in the same way that Routines are. When Transforms are used in expressions, the Transform definition (not a reference to the Transform) b...

If the hashed file stage has been created in an account, or if you have created a pointer to it in the VOC (using SETFILE perhaps), then specify "in account" in the Hashed File stage. This will enable the Selection tab. The first thing needed there is something to go in the WITH phrase (for example ...