DSXchange

Since it's client based, it doesn't matter where any given project is located. Connect to the Version Control repository on your original server like normal, then when you promote change the 'Host system' value in the 'Attach to project' dialogue box. The first time you'll need to actually type the ...

What "date format" do you need? There's always an IConv/OConv pair but if your incoming format is consistent then substring should be fine. For example: YourField[1,4]:"-":YourField[5,2]:"-":YourField[7,2] To change YYYYMMDD to YYYY-MM-DD.

Trim, EReplace and Convert will all work fine. For example:

Is your 8.x release all patched up? Installed the 'fixpack' that is available?

A CHAR field automatically pads with spaces to the full length, that's the nature of the beast. Either match the field size in your test, use a 'like' wildcard comparison or trim it in the expression.

This change shouldn't change your process at all, other than the fact that when you promote to Production, you'll point to the new 'partition'.

Hmmm... you get the event id by using -logsum first, not by looking it up in the Director.

True, forgot how restrictive the Designer Repository browser is. It is geared for working with one job at a time while the Manager is for managing... well, everything.

Please mark your post as Resolved!

Through the Manager or Designer GUI. What issue are you having? It supports all the normal Windows conventions, so ctrl-click and shift-click are your friends here.

Your syntax is invalid, which the error pointed out. The -logdetail function requires at least a 'first event id' and optionally a 'last event id'.

What 'characters' are you getting? How about posting some examples?

Great, please mark your post as Resolved then, using the button at the top of the screen.

You mean there's no option to "do not checkpoint"... and you'd have to ask IBM why that is the case.

The reason I asked hashed v. database is the use of the NOTFOUND link variable only works reliably for a hashed file. Something to keep in mind.

Interesting... that makes sense but I don't recall anyone explaining it like that. I've always assumed I had to put them back (which is no big deal) or they would be gone forever.