Strange designer procedure behavior

[Deskin, Bob]

Hmmm. Sounds like one of those "inner QUICK concept" things. For a long time
we've said that when a FIND fails and there is no PRIMARY file, then there
is no "QUICK transaction" (not to be confused with a relational
transaction). Looks like this is one ramification of that. Quick figures
that since you didn't retrieve a valid transaction that you can't update.

The NEED ALL forces the issue.

Bob Deskin              
PowerHouse Web Product Manager, Application Development Tools, Cognos Inc.
bob.deskin@cognos.com (613) 738-1338 ext 7268 FAX: (613) 727-1178
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA

-----Original Message-----
From: Paul Howard [mailto:paul@synergy.co.za]
Sent: Wednesday, October 24, 2001 12:30 PM
To: 'Whittall, Conrad'; powerh-l@lists.swau.edu
Subject: RE: Strange designer procedure behaviour


Hi,
Thanks for all of your suggestions, but it appears to be something
fundamental to Quick behaviour rather than a database issue.  On my test
case I added a 'need all' to the primary file declaration and achieved the
desired result.  It would appear that the unsuccessful find sets a flag to
prevent altered record from being set and the 'need all' put the transaction
regardless of record status.  I will have to see what happens on the
real-world program but I am pretty confident that this will solve the
problem.  Thanks again for your collective input.
Regards
Paul

		-----Original Message-----
		From:	Whittall, Conrad [mailto:Conrad.Whittall@Cognos.COM]
		Sent:	Wednesday, October 24, 2001 4:30 PM
		To:	'Paul Howard'; powerh-l@lists.swau.edu
		Subject:	RE: Strange designer procedure behaviour

		Hi Paul,

		Just a wild guess, but I think that the database transaction
that QUICK
		started when the user attempted the (unsuccessful) FIND is
probably still
		active, i.e. uncommitted.

		Assuming you are using the default transaction provided by
QUICK (with
		Oracle this will be a single transaction called UPDATE) you
might like to
		try one of the following...

		1) Commit or rollback the UPDATE transaction at the start of
your DESIGNER
		procedure; then start the UPDATE transaction again, do all
of your inserts,
		then commit the UPDATE transaction at the end of your
DESIGNER procedure.

		Or...

		2) Start a new designer transaction at the beginning of your
DESIGNER
		procedure, do all of your inserts, commit the designer
transaction at the
		end of your DESIGNER procedure. Note that this might cause a
second attach
		to the Oracle database if the default UPDATE transaction is
currently active
		(which can take some time) as Oracle can only support one
active transaction
		per attach.

		Let us know how you get on.

		Best regards,
		Conrad

		Conrad Whittall
		Manager, eLearning Services
		Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario,
K1G 4K9, Canada


		-----Original Message-----
		From: Paul Howard [mailto:paul@synergy.co.za]
		Sent: Wednesday 24 October 2001 05:20
		To: powerh-l@lists.swau.edu
		Subject: Strange designer procedure behaviour


		 

		Hello listers,

		I have a program that is showing some peculiar behaviour
that I am
		struggling to understand. Maybe someone can shed some light
on it and maybe
		suggest a workaround. 

		A Quick screen has a named designer procedure which inserts
records into an
		Oracle table. If the user enters the screen and immediately
executes this
		procedure everything works as expected. However if the user
enters the
		screen and does an unsuccessful find and then executes the
designer
		procedure it seems to go through the motions but nothing is
actually
		inserted.

		I have a feeling that it has something to do with still
being in find mode
		after the unsuccessful find and that it is not setting
altered record for
		some reason.

		Any ideas? 

		Regards

		Paul Howard


		= = = = = = = = = = = = = = = = = = = = = = = = = = = =
		Mailing list: powerh-l@lists.swau.edu
		Subscribe: "subscribe" in message body to
powerh-l-request@lists.swau.edu
		Unsubscribe: "unsubscribe" in message body to
		powerh-l-request@lists.swau.edu
		http://lists.swau.edu/mailman/listinfo/powerh-l
		This list is closed, thus to post to the list you must be a
subscriber.

		This message may contain privileged and/or confidential
information.  If you
		have received this e-mail in error or are not the intended
recipient, you
		may not use, copy, disseminate, or distribute it; do not
open any
		attachments, delete it immediately from your system and
notify the sender by
		e-mail promptly that you have done so.  Thank You.

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender by
e-mail promptly that you have done so.  Thank You.