Strange designer procedure behaviour

[John Penney]

Paul:

Please keep us informed. I've worked with PH/Quick and Relational D/B's for over 10 years (PH=20), and IIRC, these types of problems (never say never or always) were invariably caused with D/B Commit logic. The Need All construct IIRC simply forces I/O even if there was no change in the Primary File record buffer. YRMV.

Regards
>>> Paul Howard <paul@synergy.co.za> 10/24/01 09:29AM >>>
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.

John M Penney
Systems Programmer
Production Services
Information Services Department
Pierce County
Tacoma, WA 
253-798-6215
jpenney@co.pierce.wa.us