DSXchange

Yes, just create a differently named configuration file, which can be a clone of default.apt (the default configuration file). There is a Configuration File Editor in the Manager client (under the Tools menu). You can also use any text editor on the server side. By default configuration files are st...

You might investigate the Complex Flat File stage. It can deal with multiple record types.

This is the kind of task that Quality Stage is particularly suited for; you can standardize your representation of "trading as" before proceeding to other transformations. You could certainly use a Boolean condition (lots of OR conjunctions), but how would you ever be certain that you had all possib...

To reinforce the point, no passive stage in a parallel job supports an output link AND an input link (not counting reject-handling). That is, you can not update the Lookup File Set in the same job in which you use it to provide reference values. So Kumar's solution, or something like it, is the only...

Beware of course that none of these translation tools is perfect. They are all particularly bad at idioms.

The problem with on-demand for a large batch of data is that the response time will be perceived as poor. I'd be more inclined to give users a command-style interface rather than to implement SOA for large volumes. Keep SOA for the short, snappy tasks, such as standardizing or certifying a row or tw...

The connection is broken. Establish a new connection. Close the client, open a new one.

Ignore how the data browser presents the data. Send rows to a text file and tell us what you get there. Adjust the metadata to suit.

That's good. Do it with FIX now.

If there are line feed characters within the data scroll right in the Columns grid. You will find a rule that specifies "column contains terminator characters". Set this to Yes to allow DataStage to pass them as regular characters.

Highest: whatever you can screw out of them.
Lowest: whatever you let them screw you down to.
It's got to be based on your worth, your value to your client. It ought to be the basis of negotiation.

Delete the directory and all its contents. Make sure that its parent directory still exists.
Delete the entry from UV.ACCOUNT.
Delete the entry from UV_SCHEMA using VERIFY.SQL with the pathname (not the name) of the schema.

Create new project using Administrator client.

But if you've screwed the project with an inappropriate use of VERIFY.SQL none of this will help. Again, there are difficulties with INSERT. You can work around this using an F control in an inline prompt. I am not going to answer any questions about this technique. INSERT INTO UV.ACCOUNT(@ID, ...

Have you defined these environment variables, with default values, using the Administrator client? It is from these settings that $PROJDEF retrieves a value to use.

The problem with UV.ACCOUNT is that you have to build the licensing string to go into the NAME column. That's why I recommended ED. INSERT INTO UV.ACCOUNT(@ID, NAME, PATH) SELECT 'Project2', NAME, '/pathname/Project2' FROM UV.ACCOUNT WHERE @ID = 'Project1'; But if you've screwed the project ...