DSXchange

Just an update: I actually moved that update stmt from "before" level and wrote an user-defined SQL stmt to write to the database. and now I get this error : ********* SQL data type '%1' defined on column %2 is not supported. ********* the user-defined SQL is : update TableA set Col17=:17 ...

Hello all, I am using a DRS stage and writing a update stmt as a "before" SQL stmt... this is the statement I am writing : update TableA set Col17=:17 where Col1=( select max(Col1) from Table A where Col2 =:2) It generates an error : Incorrect syntax near ':'. Isn;t this how values are to ...

thanks again ket i alwys use ds.tools for cleanup..infact i just checked that the cleanup resources isn't even enabled for my job (donno y ?) Maan this is crazy.. I just tried deleting the job and it says : "Error while delting job .. RT_CONFIG871 has apparently not been deleted from directory ...

I actually dont have a TFM.... ( I donno what I was thinking when I wrote that file..I am working on tons of jobs of that setup ...so I guess I got confused) This is the structure: Table --> Hashfile. (I just read from the table and write to the hash file. As simple as that..) yeah..its showing the ...

It says the job is still running. if i recompile it works fine. now if i run it again it shows me that error message again (it doesn't go into "infinite loop" this time..) I try to delete the file explicitly using delete.file filename and system throws a Data30 error that the file is alrea...

No Ken..
I dont have any explorer session open...
infact after I reboot the machine that error message doesn't come up but the job just stays in running state (soething like an infinite loop..)

thanks ken
-Xan

Thanks Amso. Actually I already did that and still have the problem. Infact after I bounced the machine even the earlier error message doesn't come up. The job just enters the running state and stays like that unless I explicitly stop it. When this happened in my earlier reboot I deleted the job and...

Hello, This is my job: Table---> TFM--> hash file. When I run this job I get the following error message: DSD.UVOpen rm: (DATA.30) The process cannot access the file because it is being used by another process. Unable to DELETE file "Filename". "Filename" is already in your VOC f...

Thanks Chuck... I format I have described earlier is used by the existing ASCL jobs in PSFT EPM. They actually used a hash file for lookup. So the setup looks like : step 1) Table A -- > HASH_FILEA (like u described they first loaded the hash files..) step 2) HASH_FILE_A---------> TFM---------------...

*I made this post a couple of days back and had a discussion with Sumit, still the issue is not resolved among us both..can others in the group share their thoughts on this please...* ( http://www.dsxchange.com/viewtopic.php?t=88762 ) -----------------------------------------------------------------...

yup yup..infact, as i already mentioned in my original post I used the ODBC stage as a temporary fix ..
Earlier whenever we had this problem we used to switch to ODBC but in these EPM jobs was not sure if I wud want to switch since its DRS all over..

thanks anyways...
-Xan

I want all of them to be returned..I guess the by default the last row/value is returned.

Thanks Sumit.

hello,
I know DRS stage does not support 'Reference link with Multiple row result set'...
Is there any work around for this ? I am using ODBC stage just in this particular job as a temporary solution. But any other fix ?

Thanks in adv
-Xan

#### There is nothing called transaction size in the output link. Only in the table input link you have transaction size. The answer still remains the same. Even if both array size and transaction size in the input link are 1 the hash file load will start only once the input link execution is over. ...

Even if the array size of the output link is 1, every record that goes into table A will not go into the hash file immediately. It will wait for the input link execution to get over. --> thanks again sumit..now if i put transaction size as 1...would the problem persists even then ? or is the data ri...