Error: The limit for backup movements (\) has been reached. -Reply

[COLIN GLASS]

Actually, we found that the resolution below (using IF NOT
DELETEDRECORD) is incomplete.  This problem occurs in
ENTRYMODE.

Therefore the resolution should be:
IF NOT DELETEDRECORD AND (FINDMODE OR CHANGEMODE).

I have reported this to Cognos support through their query service.

Colin Glass
Manitoba Liquor Control Commission

>>> "Armstrong, Mike" <Mike.Armstrong@Cognos.COM> 10/09/98
07:28am >>>
The bug that Colin has reported revolves more around the error message
you
receive than the actual problem. It appears that in 7.23 and up on UNIX,
and
7.29 and up on HP you get *this* message instead of the *correct* message,
'You can't alter an item on a record that has already been deleted'.

The description that Cognos has for this problem is:
In a cluster (entrymode) you enter 3 occurrences, go back to the action
field, you delete the first occurrence & then you update.
In a PROCEDURE PREUPDATE, there is a LET <field> = <value> which
is being done. After you update the following message appears:
"The limit for backup (\) movements has been reached"

In versions earlier than 723/733/729 you receive the message:
"You can't alter an item on a record that has already been deleted"

It is unlikely that we (Cognos) are likely to do anything but correct the
message. The workaround, and in my opinion ultimate solution, is to add the
check IF NOT DELETEDRECORD. If you believe this is not the case, or
your
scenario is different from the one outlined above, you should contact
Support and explain the difference so that a new bug can be logged.

I hope this helps to clarify things and set the right expectations.

Cheers!

Mike

-----Original Message-----
From: hickeyt@gatesmcdonald.com [mailto:hickeyt@gatesmcdonald.com]
Sent: Friday, October 09, 1998 7:15 AM
To: David Heasman
Cc: cglass@mlcc.mb.ca; powerh-l@lists.swau.edu
Subject: Re: Error: The limit for backup movements (\) has been reached.


We encountered this problem in 729c6 and tried to convince Cognos this
was
a bug.  I am glad to see they finally realize there is a problem.
Hopefully they will come up with a fix.  The problem seems to be with the
record pointer.   It seems that when the cache limit is reached the pointer
gets lost.





"David Heasman" <David_Heasman@Thru-Transport.com> on 10/09/98
05:02:50 AM

Sent by:  "David Heasman" <David_Heasman@Thru-Transport.com>

To:   cglass@mlcc.mb.ca
cc:   powerh-l@lists.swau.edu(bcc: Thomas E Hickey/Gates/NWIE)
Subject:  Re: Error: The limit for backup movements (\) has been reached.







Colin has the problem :

Just to inform all of you of a bug that we encountered with PowerHouse
7.29C8.  In Quick, if you have a clustered screen and you are in entry
mode,
if you delete a line from that clustered screen and update, you'll receive
the
message "The limit for backup movements (\) has been reached."  This can
cause problems updating information on any number of datasets.

Cognos had already recognized this bug, and has been identified as bug
#115506.

To get around this problem, I suggested to our users to do the following:
1.  Before deleting a line, update the page/screen.
2.  Go into find mode and find the screen with the item/record in question.
3.  Delete the record and update.

This only reduces the problem.  However, to prevent it, we have found two
ways:

1.  Do not allow the users to delete items/records from the screen.  In our
case, this situation occurs in an order entry system, so the users can zero
 out
the quantity and update.

2.  Have a check if in entrymode and deletedrecord, then produce an error
message.

If anyone else has encountered this problem, and has another resolution,
please let me know.  I haven't made a permanent fix to this problem, and
am temporarily looking at option 1 above for a fix.  Any help would be
appreciated.  We are using HP3000 with a TurboImage database on
PowerHouse 7.29C8.

Colin Glass
Manitoba Liquor Control Commission

-----------------------------------

 I think this is because the records in the cluster have a "final" value
assigned.
 It certainly happens like that under 7.33 & Unix.

 You could take out the "final"s and put the value assignments into
 PREUPDATE, testing for NOT DELETEDRECORD...


Dave


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to
majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to
majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.



= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to
majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to
majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.