Jump to content


Photo
- - - - -

Data Migration


27 replies to this topic

#16 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • Gender:Male
  • Location:Bristol, United Kingdom

Posted 10 March 2005 - 03:48 PM

Just wondering how you chain the functions together? If

they work singly but give unique constraint when chained then

maybe something is running twice?
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.

#17 Phil

Phil

    Expert

  • Members
  • PipPipPipPip
  • 187 posts
  • Gender:Male

Posted 10 March 2005 - 04:24 PM

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 [ ]

#18 Neil Hunter

Neil Hunter

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 414 posts
  • Gender:Male
  • Location:Johannesburg, South Africa

Posted 10 March 2005 - 04:32 PM

Ouch, sounds like you having a really good day Phil ;)

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

#19 Phil

Phil

    Expert

  • Members
  • PipPipPipPip
  • 187 posts
  • Gender:Male

Posted 10 March 2005 - 04:39 PM

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.

#20 Guest_Hadders Boy_*

Guest_Hadders Boy_*
  • Guests

Posted 10 March 2005 - 05:14 PM

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?

#21 George Macken

George Macken

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 248 posts
  • Gender:Male
  • Location:Co. Wicklow, Ireland

Posted 10 March 2005 - 06:58 PM

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

#22 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 10 March 2005 - 08:08 PM

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!
Nothing's as simple as you think

#23 ArmChair

ArmChair

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 11 March 2005 - 08:01 AM

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.

#24 Phil

Phil

    Expert

  • Members
  • PipPipPipPip
  • 187 posts
  • Gender:Male

Posted 11 March 2005 - 08:53 AM

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.

#25 Phil

Phil

    Expert

  • Members
  • PipPipPipPip
  • 187 posts
  • Gender:Male

Posted 11 March 2005 - 08:57 AM

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.

#26 Phil

Phil

    Expert

  • Members
  • PipPipPipPip
  • 187 posts
  • Gender:Male

Posted 11 March 2005 - 08:58 AM

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.

#27 Glenn Meyers

Glenn Meyers

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 221 posts
  • Gender:Male
  • Location:St. Louis, MO, United States
  • Interests:I also raise African Gray Parrots and build hot rod automobiles.

Posted 11 March 2005 - 05:16 PM

What version of Oracle?

#28 adilsonj

adilsonj

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 15 March 2005 - 07:52 PM

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.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users