6 replies to this topic

[Marco.Bega]

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

[Mike Schoen]

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.

[Neil Hunter]

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

[Mike Schoen]

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.

[Joseph Bove]

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

[Richard Bassett]

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.