Jump to content


Photo
- - - - -

Committing changes


17 replies to this topic

#1 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 03 February 2005 - 12:43 PM

Hi all,

I'm trying to do the following :

LS1
LS2

LS1 is a transaction screen for a single file
LS2 contains more fields of said transaction file. LS2 is an optional window on the first non-key field on LS1.

Now when I F3 out changes are not being written to transaction file. When I enter through all remaining fields in LS1, my changes are being written.

I'm sure i'm missing something really arbitrary here

This is on 5.5r345 on 3.0 ES

Thanks
Neil

#2 Guest_GreenScreen Veteran_*

Guest_GreenScreen Veteran_*
  • Guests

Posted 03 February 2005 - 01:17 PM

Last Read Field in LS1 set appropriately re. first non-key field?

#3 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 03 February 2005 - 01:22 PM

Set to last key field. Get the same result if its set to my window field, or set to no last read field

#4 Joseph Bove

Joseph Bove

    ProIV Guru

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

Posted 03 February 2005 - 06:00 PM

Neil,

If I read you correctly:

LS1 goes into LS2 immediately. After returning from LS2, you press and leave the screen.

If on LS1, you have made no changes, ProIV will do a ROLLBACK for you.

You can get around this by simply embedding #COMMIT = COMMIT() in the source code. We've had to do that on maybe a half dozen (of several thousand) functions.

hth,

Joseph

#5 Richard Bassett

Richard Bassett

    ProIV Guru

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

Posted 03 February 2005 - 07:04 PM

Caveat: I don't write ProIV screens any more so I'm trading on unreliable memories :)

But.. I half recall some kind of strange ENABLE/DISABLE &#@UPDNCHILD and/or &#@UPDPARENT which were maybe relevant to the kind of problem you're having.

I never really used them and the documentation (as usual) didn't really make clear what was going on or what the precise intention was. However, might be worth you having a look if you didn't already investigate them.

Sorry to be so vague (and happy to have them explained to me if someone knows chapter and verse).
Nothing's as simple as you think

#6 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 04 February 2005 - 04:59 AM

Neil,

If I read you correctly:

LS1 goes into LS2 immediately. After returning from LS2, you press <F3> and leave the screen.

If on LS1, you have made no changes, ProIV will do a ROLLBACK for you.

You can get around this by simply embedding #COMMIT = COMMIT() in the source code. We've had to do that on maybe a half dozen (of several thousand) functions.

hth,

Joseph

Joseph, LS2 is optional not forced. Does COMMIT work with PRO-ISAM ? :) Never thought it would

Richard, thanks I saw this in the documentation, the explanation on how its used however is not the greatest and leaves a lot to interpretation

#7 Joseph Bove

Joseph Bove

    ProIV Guru

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

Posted 04 February 2005 - 04:21 PM

Neil,

I didn't realize that this was ProISAM - sorry. I doubt that COMMIT would work.

Does the call to LS2 occur before or after the last read field is processed? Also, does the user get to LS 2 by actively doing something on LS 1, or does the code force him/her into LS2? Finally, if the user changes any other field on LS1, is the file written?

Regards,

Joseph

#8 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 04 February 2005 - 04:45 PM

This has caused problems in previous releases.

The scenario is you are in change mode. You enter the keys. Then on the first enterable field you invoke a window. The window contains fields on the primary file open in the main screen. You enter data into some of these fields, and close the window. Then you press F3.

As far as ProIV sees it you have pressed F3 on the first enterable field without entering any data into the screen and it processes the F3 as a cancel.

Pressing return instead through the fields writes correctly. I would expect that entering F3 (or . return!) from any field apart from the first enterable field would result in the data being written.

I think Richard's approach might work - but I think that this is set in ProIV when records are being written in the called or nested LS. In this case I suspect no writes are being done.

I wonder if a FLD(@FLD + 1) in the Exit Logic of the window might knock the focus on to the next field, and thus avoid the problem.

#9 Joseph Bove

Joseph Bove

    ProIV Guru

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

Posted 04 February 2005 - 04:48 PM

Chris,

I was wondering if that was the problem. The COMMIT() is a perfect solution for SQL databases.

Since it is ProISAM, a somewhat ugly solution would be to just put the file in change mode in LS 2. In ProISAM, you can do this without record locking yourself. However, I don't know if the desired behavior is to have those changes written immediately in LS 2.

Regards,

Joseph

#10 Richard Bassett

Richard Bassett

    ProIV Guru

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

Posted 04 February 2005 - 06:30 PM

Hmm..

I'm getting confused here.

I think I understand what Chris is saying - because of "special" processing of the first "enterable" non-key field ProIV doesn't actually attempt to write the record(s) for that LS - because it thinks it "knows" nothing has changed so the writes would be redundant (correct me if I'm wrong pls Chris).

But Joseph says:

The COMMIT() is a perfect solution for SQL databases

If we're really talking about the same scenario a commit shouldn't make any difference at all because ProIV isn't even updating the record, right?

Joseph, you also said

If on LS1, you have made no changes, ProIV will do a ROLLBACK for you.



Did you mean you'd observed ProIV issuing a ROLLBACK to the database (that would kind of surprise me) or did you mean that no record from the relevant LS was observed to be written (not quite the same thing)?

Thanks, Richard
Nothing's as simple as you think

#11 Joseph Bove

Joseph Bove

    ProIV Guru

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

Posted 04 February 2005 - 07:31 PM

Richard,

I've seen it behave as a rollback.

We have a charge screen in our application that requires certain visit information before allowing the user to enter charges. Our processing basically behaves such that we the user enters the charge window, if no visit exists, a global window is called. They are forced to enter the visit information before they can return to the charge screen.

If the user then or out of the charge screen, the visit record was ROLLBACk'ed. Using the COMMIT, however, within the visit window solved the problem.

I don't believe that COMMIT's have any effect on ProISAM.

Side Comment: The ROLLBACK was tricky to find because it happens so fast, the end user never sees it.

Regards,

Joseph

#12 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 07 February 2005 - 05:00 AM

Chris, thanks for the reply. You've summed it up perfectly. I have read the same file in LS2 and it works fine now, although i'm not too happy about coding this way. Have also tried a fld jump, but this didn't work either. Just wish it was on SQL would have made life so much easier

Thanks for all your help guys

#13 George Macken

George Macken

    ProIV Guru

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

Posted 08 February 2005 - 07:29 PM

I recollect working on a Pro-iv application - where the first field to all of the screens was a
Continue Field - from where the User entered return and then moved to the first field - would having a "Continue Field" before your field overcome the problem you are encountering

Rgds

#14 Neil Hunter

Neil Hunter

    ProIV Guru

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

Posted 10 February 2005 - 07:54 AM

Thanks for the reply George

Yes it is possible but not ideal. I'm trying to get my screen to be fully GUI, and not rely on where a user presses enter

#15 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 10 February 2005 - 08:03 AM

Hi Neil

If you're working in GUI we've found it useful to change the way you think about screen design and create artificial commit points.

Basically we load all the data on entry to the screen (into either display scratches or workfiles / memory files). On exit from the screen you then call an update LS (or not depending on how the screen exit was achieved). This then removes the file reads from the actual data entry section of the screen and gets rid of the sort of problem you are experiencing here.

It's really the best way to handle it in a language that wasn't really designed for GUI screen development.

Cheers

Mike



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users