DSXchange

It should have been, but who knows? Your problem, I'm 99% sure, is that you had a database connection open waaaay too long, probably were dealing with either rollback segments on the load query, snapshot segments on the source query, a whole host of issues. This folks, is why I recommend getting the...

My guess would be that your runtime is so obscene (hours) that your connection is timing out. 16 million rows, this job must be riding on only 1 cpu, waiting forever on the OCI lookups, I'd guess you're runtime is somewhere over 8 hours without even knowing much about what you're doing. Unless I'm t...

Are you using ODBC or the OCI stage? What version of the client software are you using, the 8i or the 9i? Which OCI stage, the 8i or the 9i plugin stage? Is your issue viewing data? Let's see the actual error messages if you've got them. I have about 50 more questions but could use your help narrowi...

You need to import table definitions of your target and load it into the ODBC stage definition. You need to map the source data into the form the target will accept. If your ODBC target requires the date information in a specific form, you must manipulate the data into that form. If your target is S...

Your link statistics are available for export during and after a job has run. You can use multiple methods to extract these statistics, either use a DS BASIC routine and call the job APIs that give you this information; or use the command line program dsjob with the appropriate switches to extract l...

Thomas, I posted a routine specifically to replace that AWEFUL SDK routine. It's posted here:

http://www.dsxchange.com/viewtopic.php? ... eyparallel


The details are in the postings.

Start by telling us what the job is supposed to do. Are there any before-job, before-transformer routines? Any log messages? What about checking "ps -ef |grep phantom" to see any active processes? Can you give us a little more information please?

If you're using multiple instances to divide up a source file and multi-job process it, then I assume the same hash file is a target in all jobs and you're refering to write-delay caching? So turning it off allows the jobs to finish, but having it enabled causes it to fail. Any chance you're bumping...

XP Professional only

You've posted in the wrong forum.

To answer your question, the difference between cron and an enterprise scheduler are vast. You need to research tools like Autosys, Tivoli, etc and understand what those products do. cron is to a shovel what an enterprise scheduler is to an earth mover.

If you use the "Clear Hash File" check box in a job design, the hash file will be cleared when the input link starts up. Therefore, if you have a reference to that same hash file in a previous transformer stage, the hash file WILL be cleared before the first row is processed.

Wow, nobody likes my earlier suggestion. You guys are having too much fun trying to make clear.file work from unix command. I don't think you can do this!!!

My earlier suggestion will work.

No. The number of qualifiers are too numerous, you're better off contemplating the design intent and going back to the functional requirements.

Sign up at www.kennethbland.com for access to my private stash.

Sorry for not piping up earlier, the method you need to use sounds a little hokey, but it works. What you do is create the hash file, then copy the contents of the empty hash file subdirectory into a parking space. Whenever you need to clear the hash file, simply recopy the empty DATA.30 and OVER.30...