DSXchange

Or the "online" help from the client tools. Switch to the Index tab, type "DS" and you'll be right there.

Can't you include that Type column as a key for the lookup and then hardcode either the 'Buy' or 'Sell' value in the field used for the lookup itself?

A pathing issue, it would seem. Either fully path the command, add its home directory to your $PATH or 'cd' there first and then "dot slash" it.

But can you guys expplain me as to why its not working if i do lookup directly with the database Not possible to say without all of the gory details we'd need or actually seeing how you implemented it. All I can guess is that your lookup query wasn't keyed correct. [shrug] The hashed file is the be...

Right - it is a label, key for a record in a hashed file and one I typically name after the target it will be used in. All this would be revealed by a simple double-click on the routine itself and an inspection of the code. You would then learn the name of the hashed file and could thus query or sou...

And all of your lookups are failing? You didn't explain how you implemented them - hashed file, direct database, what? Have you debugged the job to see why your keys aren't matching?

More details needed. How, exactly, are you checking for existence? Business key hashed lookup for the surrogate to update?

Database triggers? A 'before insert' trigger that raises an error when that value is seen could work, I suppose, depending on your warning level. Or you could just call DSLogFatal() in the job itself.

And I prefer to capture them all and then conditionally abort the job if the error file is not empty and that is the requirement. That way all problems are known, not just the first one.

Technically.

Why abort? Why not capture it and move on?

Those routines provide a unique value every time they are called. They track the last value used and increment it by one, simple as that. You would need to detail your job design and how you are determining inserts v. updates before anyone could help with your other issue.

It needs to be a string, a hard-coded value. For example, if your target table is named TEST.FRED then use KeyMgtGetNextValue("TEST.FRED") as the call.

Sequential files allow nulls, yes. The Server product makes handling them a little easier, basically you'll end up with a empty string / field unless (of course) you are writing out to a fixed-width file. In that case you'll need to supply something of the appropriate size for the field, typically s...

You use KeyMgtGetNextValue('X') and for every discrete value of 'X' it will track an incremented surrogate value. We used the target table name for 'X', including owner if needed to make it unique.