DSXchange

Yes.

And it's all in the manuals.

That is correct. Account = project. This method adds a VOC entry.

And we would appreciate it if you were to post what you get in ResultText, as requested.

DataStage handles every character that can be encountered in business data processing in all known data sets.

Without knowing precisely what you mean by "ASCII extended" it's not really possible to indicate whether there's anything you need to do or not.

Well, it's definitely been discussed before. You can't do it within the job - job parameters are fixed when the job starts. Use whatever method you like in a job sequence to read the lines from the parameter file. Load these up into, say, user variables and use these to supply parameter values to th...

DataStage is not supported on Vista. Any edition. I'd be surprised if it even installs.

You will get the warning irrespective - it's metadata-driven.

Create a local message handler to suppress it.

VOC is the nearest thing to a database index in DataStage, but it's much more than that. I'm not going there today. And, yes, the intention is that of "vocabulary" - it contains all the words and tokens that the command parser needs to understand. Except, of course, for those in file dictionaries.

The first suggestion won't work, because you can't have an assignment statement in an expression. (In.string[4,1] = '') will be treated as a comparison expression and always return 0 (for False).

The second suggestion is a good one.

The latter code, with the SQL... functions, is leveraging the BASIC SQL Client Interface. In your previous post, is there anything in ResultText when SystemReturnCode is non-zero? What you're doing in this example is creating a virtual BAT file - SystemReturnCode captures its exit status and ResultT...

You're not going wrong anywhere - it's just that the hashed file was created in a directory, so there's no VOC record pointing to it. Queries require the VOC pointer. It can be created with SETFILE: SETFILE /dir/dir/.../HASHRECORD HASHRECORD You guys dealing? Why do you need records about hash?

The file dictionary is where the metadata are stored. A better analogy is "system table" rather than index. Its presence or absence will make no difference whatsoever to how fast you can extract or load rows. The file dictionary exposes column names, how they are mapped to the record structure, and ...

You need to have $ORACLE_HOME/lib32 ahead of $ORACLE_HOME/lib in SHLIB_PATH, because DataStage is a 32-bit application.

Yes. CREATE.FILE creates a VOC entry, creates a file dictionary and adds an @ID item to the file dictionary. The mkdbfile does none of these things. (It is invoked twice by CREATE.FILE, once to create the data portion, the other to create the file dictionary portion). CREATE.FILE also sanity-checks ...