RE: Developer 2.1 problem/question

Ken,

I'm a little bit confused on some of the details about the positioning of the cursor; but, it sounds like your "real" problem is a synchronization issue. Two "views" of the same data, one high level and one detail, with changes made to the detail needing to be reflected on the high level representation. Instead of working the problem as you described, maybe a different approach could be used.

Instead of the two block approach you are using, and all the hoops you are jumping through, you might consider a single block and "mirror items" using the "synchronize with item" property. Suppose the table has 10 columns, and, you display 3 on the master screen, and, all 10 on the detail screen. For the sake of the example, assume the master block is a mutli-row block, say 15 rows in tabular format, and, the detail block is a single row with the fields laid out in "form" manner. Here is a brief overview of how to tackle the problem:

1. Create a single block, tabular format, with all 10 columns and Number of Records Displayed set to 15.
2. Copy and re-paste just those items you want on the master screen. Rename the copies and set the "synchronize with item" property of each to point back to its "real" field.
3. Move your 7 fields, plus the 3 mirror fields, to a new canvas and set the Number of Items Displayed to 1 for each field. Arrange them however you like. Or maybe you still want this to be a multi-record block as well.
4. Using triggers and/or next/previous navigation item properties, tweak the first and last items on each screen so that next item and previous item navigation events stays within the appropriate set of fields.
5. On the master screen, set the Insert Allowed and Update Allowed properties to false for the 3 fields.
6. Take steps to prevent DELETES from the master screen -- a number of ways you can do this.

What this does is get rid of the synchronization problem altogether. There is no need to requery in the master block to see changes made in the detail block. When you place data in the mirror items on the detail screen, changes to them are reflected in the master screen. Same thing for adding a row and deleting a row in the detail screen since you are working with the same record -- just presenting two different views of the data. You could vary some from what I outlined above depending on your exact needs.

If this isn't what you need, sorry for going on for so long. If it sounds like it will work, and, you still have some questions, feel free to drop me a line.

Regards,

Larry G. Elkins
The Elkins Organization Inc.
elkinsl_at_flash.net
214.954.1781

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Ken Ballard Sent: Wednesday, May 24, 2000 5:04 PM
To: Multiple recipients of list ORACLE-L Subject: Developer 2.1 problem/question

We are trying to create an application using Developer 2.1 and are having the following problem.

The first block runs a query producing a listing of all the master records. Users can narrow the executing a query to get specific records, like all records with a last name of Smith and the first name starting with T. This listing contains a few key pieces of data, but does not allow inserts, updates or deletions. To insert, update or delete a record, the user has to choose(click on) the specific record to be worked on. The double click performs a go_block to the second block, pulling up the specific record with all of its data. To get this to work we set up a relationship with block one being the master and block two being the detail, joined by the key. The way we set up the master/detail relationship for the same table may be causing our problem.

The problem is that when users add or edit a record and then save the changes, they are returned to the first record in the query from the first block. This is because to show the changes just made, we have to return to the first block, requery the master records and return to the second block with the changes. We would like the users to be returned to the record they are working on.

We did get around this problem when working with the full query list in block one - by setting a global variable "cur_rec" equal to the :system.cursor_record. When we make changes, save, and return to block one to requery we do a go_record(:global.cur_rec). This takes us to block 2 for that same record. However, if the users do an execute query and narrow the listing, the user always returns to the record with the same :system.cursor_record, but of the full query, not the narrowed query.

It seems that there should be an easy way to always return the user to the record they just processed. Any suggestions would be greatly appreciated. Received on Thu May 25 2000 - 18:11:18 CDT