All,

I have a function recently gives me the "Error Code 2, 018-Error in writing file : AR_FIN"

I thought that error only happens for PRO-ISAM file. But my file AR_FIN is an oracle table....

What normally mean for 018 error to an Oracle table?

I have regenned all the files and functions and have made sure the file definition is of type ORA. The table is dropped and created again. But the error still exist. What can I do?

Regards,

Vol

Hi,

When you get the error and you have returned to the kernel prompt, run a function called @RFUNCT and tell me what the values of the following vars are...

@MSGTEXT
@MSGARGS
@SYSERR
@SYSERRTEXT

Rob D.

Hi Rob,

@MSG [18]
@MSGTEXT [(ERROR CODE 2) 018 - ERROR IN WRITING FILE - AR_FIN]
@MSGARGS
@SYSERR []
@SYSERRTEXT []


I cannot see @MSGARBS as it is overwirtten by the @MSGTEXT

Does this help?

Regards,

Vol

Rob,

I enabled the trace and captured the trace file. Will this help to investigate the problem. THx,

Regards,

Vol

****Edited****
I have removed the attached trace file for your security. These files could have your customer data or login/password data.

It would be best to email me the file, in the future.
Rob D.

Hi Vol,

I could not find anything in particular.

You could maybe check the assignment of the USER_DATE fields in some of the files, because in the trace it looked like this var was being set to null in some instances. I would not say that this is definatly it, but you could have a quick check.

It seems to start going wrong in W_ARAUCS in LS12 with the insert to AR_FDET.... but it could just be the trace file not being correct.. or me reading it wrongly

Also if you want, if you email the function that falls over and the global funs it calls (ie.. ARAPPUCS & U_FNLOAD,W_ARAUCS,U_NXTVAL,U_TERMSC,U_SYGIV.. I think) and also the file defs.

Maybe I can see a bit more..

Rob D.

Vol,

Since Errror Code 2 is Unix "No such file or directory" and you seem to have no SYSERR values, it looks likely to me that you are inadvertently running something that was genned where the file definition WAS in fact Pro-ISAM or C-ISAM..

Are you quite sure that's not the case?

Or maybe there's some problem with a sequential (SEQ or BIN) file..?

Hi,

I would very much doubt that it is that, it seems to be the INSERT command into the oracle DB that is failing....

From the Trace File:

191914.921-OraCmdParse: SQL STATEMENT(length = 365) =
191914.921-  INSERT  INTO AR_FIN(AR_CCN,AR_FIN_SEQ,BANK,AR_DEP_DATE,AR_DEP_SE
191914.921-  Q,CREATED_DATE,USR_,REPORTED,CCN_TG_SEQ,USER_ALPHA1,USER_ALPHA2,
191914.921-  USER_ALPHA3,USER_NUM1,USER_NUM2,USER_NUM3,USER_DATE,USER_TIME,AS
191914.921-  OF_DATE,CCN) VALUES (:V00000,:V00001,:V00002,:V00003,:V00004,:V0
191914.921-  0005,:V00006,:V00007,:V00008,:V00009,:V00010,:V00011,:V00012,:V0
191914.921-  0013,:V00014,:V00015,:V00016,:V00017,:V00018)
191914.921-OraCmdParse: Statement Parse OK - rc = 0
191914.921-OraCmdIBind: INPUT BIND - Total Columns = 19
191914.921-  Col 1 : BindType 9, Name :V00000
191914.921-  Col 2 : BindType 9, Name :V00001
191914.921-  Col 3 : BindType 9, Name :V00002
191914.921-  Col 4 : BindType (EXTERN) 1, Name :V00003, DataLen 10 = '          '
191914.921-  Col 5 : BindType 9, Name :V00004
191914.921-  Col 6 : BindType (EXTERN) 1, Name :V00005, DataLen 10 = '20030430  '
191914.921-  Col 7 : BindType 9, Name :V00006
191914.921-  Col 8 : BindType 9, Name :V00007
191914.921-  Col 9 : BindType 9, Name :V00008
191914.921-  Col 10: BindType 9, Name :V00009
191914.921-  Col 11: BindType 9, Name :V00010
191914.921-  Col 12: BindType 9, Name :V00011
191914.921-  Col 13: BindType (EXTERN) 1, Name :V00012, DataLen 1 = '0'
191914.921-  Col 14: BindType (EXTERN) 1, Name :V00013, DataLen 1 = '0'
191914.921-  Col 15: BindType (EXTERN) 1, Name :V00014, DataLen 1 = '0'
191914.921-  Col 16: BindType (EXTERN) 1, Name :V00015, DataLen 1 = ''
191914.921-  Col 17: BindType 9, Name :V00016
191914.921-  Col 18: BindType (EXTERN) 1, Name :V00017, DataLen 10 = '20030501  '
191914.921-  Col 19: BindType 9, Name :V00018
191914.937-OraCmdExec: Execute Failed : XCPT_THROW rc = 1403
191914.937-qgCmdExec: XCPT_RAISE
191914.937-qgSqlFInsert: XCPT_RAISE
191914.937-sysfwrt: exit, stat -351, errno/fnl.filerrno 0/-351
191914.937-sysfrd: isfd 1, SY_EQ: [buflen 96]: A R _ F I N ~ ~ F 0 1 8 
191914.937-sysfrd: exit, stat -1, errno/fnl.filerrno 0/10012
191914.937-sysfrd: isfd 1, SY_EQ: [buflen 96]: S Y S T E M ~ ~ E 0 1 8 
191914.937-sysfrd: exit, stat 42, errno/fnl.filerrno 0/10012
191914.937- S Y S T E M ~ ~ E 0 1 8 1d0 1 8 ~ - ~ E R R O R ~ I N ~ W R I T 
191914.937- I N G ~ F I L E ~ -

Its the value for USER_DATE that is giving me a bit of concern, since it says that it is expecting a length of 1, but the value sent is ''... but maybe I'm wrong.

Rob D.

OCI return code 1403 ("rc = 1403") means NO_DATA_FOUND as far as I remember.

Usually I think this occurs at end-of-fetch for a SELECT statement.

Not sure why you're getting it for a simple INSERT (?) but maybe it helps to know this?

you may be writing a null value to a non-null field.

This is what I suspected.

But, there are other occurences of this within the trace file and it does not result in an error.

So it got me a bit confused.

Rob D.

Richard Bassett is on the right track... He at least spotted the correct error.

Richard Bassett is on the right track... He at least spotted the correct error

What do you mean by that?

How can an INSERT statement error with NO_DATA_FOUND? Or is it the USER_DATE field that is being assigned to '' that is giving the error when the INSERT is done?

Do you know what is causing this error?

Thanks,

Rob D.

Is it possible that you have an insert trigger defined on that table that is doing a select that returns no data ?

Trigger?

There is a way to find out.

SELECT * FROM USER_TRIGGERS WHERE TABLE_NAME = 'YOUR_TABLE'

Cheers!

Ooooops, yes, there is a Trigger on this table.

How do I check if this Trigger causing the error?

Thanks for all