DSXchange

Something else is wrong - an 'empty' source file should not cause a job to fail. It should simply run and process no records - no errors, no warnings - just start up and shut back down and do a whole lot of nothing. If the job aborts, it should only be because the source file does not exist, or perh...

Well, simply put - you are not authorized to use cron.

The user you are trying to schedule the job under does not have permissions to create cron jobs. Speak to your SA and have the user added to 'cron allow'.

That's it? Bummer...

When I needed to use it, it told us exactly what was wrong and it took my SA about two shakes to correct the issue after that.

Good luck! Let us know what you find.

It's just you, Larry.

Andy, if you check the posting I linked to earlier, it will show you how to set the debug option for dsrpc - and then it will tell you why it can't start.

What database?

There should typically be a tab on the stage you are using for 'Transaction' control. One of the fields should be 'Transaction Size' - set this to 50 to commit every 50 records.

That being said, recognize the fact that this will complicate your restart strategy.

Wow Ray? That's exactly what I said. (where's a big pouty face when you need one?) Ray just provided the actual code to go along with it.

If you own the table, then you should be able to truncate it. If you know how to delete from it 'after job' then you know how to truncate it as well, it's just a slightly different SQL statement. So, your answer should be Yes. That being said, I still don't see this as a Good Practice. Seems like it...

It is entirely legal for them to be there (since "" is a known value, unlike NULL), but is clearly causing a problem. Ah well, Mea Culpa. However, I do seem to remember a post a little while back where someone had been using 'empty strings' in hash file lookup keys under 5.x but it no longer seemed...

Using a delete would leave empty blocks (holes)in the disk space. Therefore always use the truncate facility I think this is much less of an issue nowadays with modern storage sub-systems and improvements made in underlying database structures and space management like that built into Oracle. It do...

They were stating that the dsrpc deamon would not even start. Your OCI problem is a different animal. On a 64-bit UNIX server, perhaps? You may have run into the issue where the OCI9 stage does not support 64-bit libraries, you must include $ORACLE_HOME/lib32 (not just simply 'lib') in your Shared L...

We shall see, when Raj next visits. That's why I prefaced things like I did - if the fields are of a consistant length, 10 versus 3, it should be easy to correct. After that, it will depend on exactly what is in the fields. '10 digit character' doesn't tell me specifically if it is 10 digits or 10 c...

That's an interesting thought! I seem to recall a Ray post around here somewhere where he was involved in something like this Back In The Day. I recall he admitted to being disqualified even though his elapsed time was the lowest... something about resetting the system clock part way through his job...

And just to further help understand what you are trying to do... Under what circumstances would you be looking up anything where both keys are empty strings - in essence null - and expecting a result other than what you received? You can't have a hash record where key fields are null any more than a...

Do you really need to create two files? I would think you could work with the file as is, if the mix-up is as simple as it sounds. Declare both the 3rd and 4th fields as 10 characters on the input side. Check the LENgth of the actual data and swap fields if the data in the 3rd column is 3 digits lon...