DSXchange

The other output ends up populating the fact table. It has (typically) the surrogate key of the dimension table and does not have the business key. It also, obviously, has the measures. A job to populate a star schema with four dimensions might look like this: +------+ +------+ +------+ +------+ | |...

Please explain exactly how you're doing that. You can not simply "set" the value of a parameter in a parameter set externally, other than when you're creating it. What you can do is declare the parameter set to have one or more values files, and write to those files, then declare the file ...

You should never have deletes in a Type 2 dimension. The SCD stage does not behave in the way you require. It generates a single output for the dimension table, which is typically set to Upsert. You can do what you require with Change Capture, Compare or Difference stage followed by Transformer stage.

So, what output ARE you getting?

How are the columns mapped on the output of the Lookup stage?

Yes. But it's a lot easier with a server job and its Folder stage.

Yes, you can do this at field level by editing the extended properties of the field in the Columns grid. Double-click on the row number in that grid, or right click anywhere in the row in the grid and choose Edit Row.

The $ needs to be inside the sharp signs, for example #$ORA_USER#.

But the mechanism also requires that you pass them through job parameters - you can not use project-defined environment variables where a job parameter is expected.

They are both correct. When you import via ODBC Connector, the ODBC driver converts to what is right for ODBC. When you import directly (or via the orchdbutil facility) you get the data type that the OCI reports. As a general rule oversizing VARCHAR data types is less likely to cause problems than u...

What do YOU understand by this error message? Even from the sparse information you have provided I can tell that the error was thrown in the first line of the file (offset 0) and that there were more bytes in that line than the metadata specify. Chances are that you need to, but have not, specified ...

The error message indicates that whatever value is being passed to pProcessDate is not a valid date or is not a valid date format. What is your default date format? (It's probably YYYY-MM-DD.)

It's been a while but, basically, the routine attached to the relevant jobs and periodically scanned their logs to determine whether any non-Info events had been logged since the last scan. If there were, then those events were copied to a local store - I think it was a text file.

Your understanding does not correspond with mine, in which each run creates a file in &PH&. But I have not tested this recently. Certainly that was the case in version 5.2.

This "issue" has been around since version 1.0, in which the ORABULK stage was an active stage because they felt the need to support after-job subroutine through which sqlldr could be invoked with user-supplied options. I guess it's just continued through.

is it possible to get that information by querying DS_JOBS? No. This information is stored in other tables, particularly RT_STATUSnnnn (there is a separate table for each job). And also is there any way to get the count of jobs which are in compiled state in a project? This information also comes f...

Please confirm that your job design looks like this: +-------+ | | | Ref. | | | +---+---+ | V +-------+ | | | Copy | | | +-+---+-+ | | ref1 | | ref2 V V +-------+ | | ------> |Lookup | -------> stream | | +-------+