DSXchange

I use the dscmdexport.exe command wrapped in a batch script that is scheduled from Windows client (that contains DS client) to create the dsx file. It creates a single dsx file for a project and contains jobs, routines, table defintions, executables etc. Whenever I want to split them into individual...

Sorry, I did not realize you use PX. The above code will only work in a server job, or in a BASIC Transformer.

Assuming your date comes in with YYYYMMDD format, you could use

Use the built-in transform, KeyMgtGetNextValue('YourSequenceName'). In case there is concurrent writing to the same table, you could use KeyMgtGetNextValueConcurrent('YourSequenceName')

Dunno if you guys solved the problem, but I sure did not get the error during the above post.

I have been getting the same error more frequently lately. Whenever it stalls, I just wait for a few seconds and go back and then to the original post, in order to avoid a double post.

It is kind of annoying specially when you have many questions or are trying to reply to other's problems.

Thanks gateleys, I will sure do that and my issue was DB transaction/rollback handling, how to best control this for a whole job/service, DB transaction takes place only at the end of the job stream, if everything is successful. Also, rollback of data for a DB stage (or something else in the job) f...

rahul8055 wrote:

gateleys wrote:If you do not specify the key field, how do you expect the matching to take place?

Do I need to specify it as primary key?
can you please expand your answer


thanks,
Rahul

yes.

In the transaction tab I could see record count Is that record count that is specified as 2000. and array size is 2000 and auto commit mode is off do I need to change anything? thanks Rahul Here, the Record count is the commit size and the array size is the number of rows that is transferred in one...

If you do not specify the key field, how do you expect the matching to take place?

The ODBC, when used as a target, does have the "Rows per transaction" in the Transaction Handling tab.

Did you delete/rename the previously scheduled job, and then created another job under the same name? I remember something similar that happened to us in the past. I can't remember the exact nature of the problem, but it had to do with delete/rename of jobs.

That's weird. We use 7.5.1, and have queries that are waaayyy longer than that, and we haven't had any issues... even with line feeds.

Neat, but I will pass.

Array size can surely give you faster reads (and writes) if you can test for the optimal setting. Never used prefetch in OCI.