27 replies to this topic

[Chris Mackenzie]

Just wondering how you chain the functions together? If

they work singly but give unique constraint when chained then

maybe something is running twice?

[Phil]

The functions are tagged on EXIT LINK.

The latest error, after all day tinkering ;

This occurs on the 2nd executed function ;

The following error occurred, causing your function to PLFUNC
be aborted and an automatic rollback to be performed. 16:37:59

@MSG [366]
@MSGTEXT [366 - SQL ERROR: ]
@MSGARGS [ ]

@SYSERR [016E ]
@SYSERRTEXT [ORA-01003: no statement parsed ]


Press [ ]

[Neil Hunter]

Ouch, sounds like you having a really good day Phil

You doing any fancy SQL within the conversion or using PL/SQL ?

[Phil]

My head hurts, and my eyes are heavy.

Each conversion function is deleting from the .pro file and adding to the table.

The only logic is before read on each file ENABLE(&#@SUPPADDRD).

There is also an interation count of 500 in Other Options.

[George Macken]

Phil

Earlier you menioned only having problems if the Pro-Isam files you are processing have the CO-DIV = Y.

Copy the Pro-Isam filedef, remove the CO-DIV flag, set the alternate as the original phsical .pro file, insert XX_COMP as key field 1 (lenght 3), before the existing keys.
(I would not use any existing bootstrap variable name)

You should now have a file definition that is not CO-DIV = Y and which you should be able to use in the conversion functions.

Does problem still occurr ?

Probably advisable that you dont have the PRO-ISAM files in Delete Mode.
Once the conversion is finished, you can ischk *.pro and get the record counts, then SELECT COUNT(*) TABLE_NAME to get the no. of rows, hopefully they are same, andditionally randomly check the ORACLE table contents (Numerics and Date Fileds etc,) and maybe a no. of weeks/months after go-live get rid of the pro-isam data.

On the ORACLE side of things, have you a DBA (or skills), is the Rollback space coinfigure correctly, have you loads of disk space etc for your ORACLE DB.,

Hope this helps


George

[Richard Bassett]

Phil,

These functions are really short right?

Just post the textual documentation for one of the functions plus the filedefs it uses plus the relevant SQL CREATE TABLE onto the forum and let people see what you're actually doing.

Pick the one with the simplest filedef in fact.

It'll be a really simple problem but it's hard to just guess without the info!

[ArmChair]

Phil,

It is quite likely that the file definition in PRO-IV does not match the table definition in Oracle. I have had a problem like this quite sometime back and I figured out that this was the cause of the problem. Perhaps it is something else in your case, but it is worth a second look, IMO.

[Phil]

I just asked the help of our resident Oracle chappy for any ideas on that message.

He suggested you get onto Google and taake that last part of the message, the bit about Parsed on it. He says "The answer will be forthcoming".

Might as well try it?

Unfortunately we had already tried that.

[Phil]

Phil

Earlier you menioned only having problems if the Pro-Isam files you are processing have the CO-DIV = Y.

Copy the Pro-Isam filedef, remove the CO-DIV flag, set the alternate as the original phsical .pro file, insert XX_COMP as key field 1 (lenght 3), before the existing keys.
(I would not use any existing bootstrap variable name)

You should now have a file definition that is not CO-DIV = Y and which you should be able to use in the conversion functions.

Does problem still occurr ?

Probably advisable that you dont have the PRO-ISAM files in Delete Mode.
Once the conversion is finished, you can ischk *.pro and get the record counts, then SELECT COUNT(*) TABLE_NAME to get the no. of rows, hopefully they are same, andditionally randomly check the ORACLE table contents (Numerics and Date Fileds etc,) and maybe a no. of weeks/months after go-live get rid of the pro-isam data.

On the ORACLE side of things, have you a DBA (or skills), is the Rollback space coinfigure correctly, have you loads of disk space etc for your ORACLE DB.,

Hope this helps


George

George, We had tried renaming the new primary key to PLCOMP instead of @COMP but still the problem remains.

I also tried having the pro-isam in lookup mode instead of delete, which also made no difference.

I will have to check the Rollback space configurement.

[Phil]

Phil,

These functions are really short right?

Just post the textual documentation for one of the functions plus the filedefs it uses plus the relevant SQL CREATE TABLE onto the forum and let people see what you're actually doing.

Pick the one with the simplest filedef in fact.

It'll be a really simple problem but it's hard to just guess without the info!

I quite agree Richard, I'll see what I can do.

[Glenn Meyers]

What version of Oracle?

[adilsonj]

A couple of suggestions:

The "No statetment parsed" message might occur as a result of an invalid primary key/unique index - try issuing a "alter index PK_MYTABLE rebuild" where "MYTABLE" would be your ORACLE table name. If this fails, you may have duplicate data that invalidated a unique index.

Your issue regarding the functions not linking to one reminds me of some ProIV security problems. If you are using @COMP, or you have @OPR in your ProIV file definition, you may be encountering security violations that knock you out of ProIV. Another possibility - if @COMP is set to Null/blank at the start of your function and runs through a given file, it could possibly end up with different data and thus another security error.

I'd suggest ensuring you have saved and reset @COMP at the start and end of each function, or alternatively not use @COMP in the file definition.