Jump to content


Photo
- - - - -

Oracle Conversion and Lsexit


6 replies to this topic

#1 Marco.Bega

Marco.Bega

    Advanced

  • Members
  • PipPipPip
  • 77 posts
  • Gender:Male
  • Location:Milano, Italy

Posted 10 July 2005 - 07:34 AM

Hi,
my customer use pro-iv 4.6, and now it migrate some table from proisam to oracle.
We have a find a difference.
Example
LS1
Screen
LS2
Paging
Work File with a same record
Exit Paging
Field with a question confermation ?
If you response "Y" i execute internal logical screen in delete from "New Oracle Table -"
IF $CONF = 'Y' THEN LSCALL(3) LSEXIT;
EndScreen
LS3
Internal Update
ANAGRA DELETE MODE

Before when the file was un proisam file then function delete all the records.
Now the file migrate to oracle the function dosen't delete any records!!!!!!!
Becuase the system response to rollback.

Regards
Marco

#2 Mike Schoen

Mike Schoen

    Expert

  • Members
  • PipPipPipPip
  • 198 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 11 July 2005 - 12:54 PM

You can fix this function by adding
SQL
COMMIT
ENDSQL

before the lsexit.

I just hope that you dont have a lot of functions that do this.
This is a side-effect of pro-iv issuing commits at the end of ls1 when ls1 has oracle tables - if you dont finish it, you dont get commits.
I have also seen functions with all pro-isam files call globals with oracle files that dont commit.

And my favourite: a paging primary ls, window on the first input field to change oracle child records, and down-arrow after closing the window results in a rollback instead of a commit. I get around this by calling the window in window logic, and adding "$INPUT = ' ' " to make pro-iv think there was a keystroke, so that it jumps to the next field and commits.

#3 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 11 July 2005 - 02:59 PM

Uh... Mike,

You can fix this function by adding
SQL
COMMIT
ENDSQL


I hope you are aware that's strictly forbidden.. the PRO-IV documentations says the following re. embedded SQL:

 CAUTION 
No transaction processing (commit or rollback), cursor manipulation or database connection or disconnection statements are allowed. All of these functions must be handled by PROIV.

#4 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 12 July 2005 - 03:42 PM

Rather use #C = COMMIT(), it does the same thing anyway :D ;)

#5 Mike Schoen

Mike Schoen

    Expert

  • Members
  • PipPipPipPip
  • 198 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 13 July 2005 - 01:00 PM

Oops, never saw that.
That being said, we have also not experienced any problems, other than the same issues that would probably arise using the commit() logic statement, ie trying to update a record no longer locked that others have modded.

#6 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 13 July 2005 - 01:16 PM

Guest,

I hope you are aware that's strictly forbidden.. the PRO-IV documentations says the following re. embedded SQL:

 CAUTION 
No transaction processing (commit or rollback), cursor manipulation or database connection or disconnection statements are allowed. All of these functions must be handled by PROIV.


Are you saying that embedding a commit is not supported - in lieu of using the COMMIT() command?

I can't imagine that ProIV would have provided (and documented) a command like COMMIT() if its use were forbidden... My understanding would be that if you use the COMMIT() statement you are allowing ProIV to handle the transaction processing.

Regards,

Joseph

#7 Richard Bassett

Richard Bassett

    ProIV Guru

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

Posted 13 July 2005 - 05:28 PM

Hi Joseph,
Guest was actually me forgetting to login..

Are you saying that embedding a commit is not supported - in lieu of using the COMMIT() command?

That is exactly what I was saying. It's what the documentation says ;)

I can't imagine that ProIV would have provided (and documented) a command like COMMIT() if its use were forbidden... My understanding would be that if you use the COMMIT() statement you are allowing ProIV to handle the transaction processing.

Ah, we're slightly at cross-purposes I think.

COMMIT() is of course supported and allows ProIV to handle the transaction processing but SQL..COMMIT..ENDSQL is expressly forbidden and is not equivalent (I think because ProIV does not necessarily parse the SQL and therefore will not know a transaction has been terminated.. which is a BAD thing.)


Mike,

That being said, we have also not experienced any problems, other than the same issues that would probably arise using the commit() logic statement, ie trying to update a record no longer locked that others have modded.

I think the problem is that if you use SQL..COMMIT..ENDSQL then even running with SQL_TRANSACTION_ERROR=Y won't trap the problems whereas if you use COMMIT() it should..


HTH, Richard

Edited by Richard Bassett, 13 July 2005 - 05:29 PM.

Nothing's as simple as you think



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users