Dennis,
 
Maybe you could do up a sample in Concomp and send it to RDCC?  I'm not sure it's a bug, though.  The cursor in the slave table isn't "advancing".  The REFRESH, just re-fetches the data from the table, it's not doing anything with the cursor.  (That's why you get the cursor error when you try to move in the table after you delete, without refreshing first.)  The work around is to
 
1. Delete your rows
2. Refresh your tables
3. NEXTROW
4. PREVROW
 
OR, if the user is always removing the first record in the record set, instead of NEXTROW,PREVROW, you can do :
 
PROPERTY TABLE toptablename 'FIRST'
 
Which will take the user to the NEW first record in the recordset (after you refreshed it).
 
Dawn


From: Dennis Fleming [mailto:[EMAIL PROTECTED]
Sent: Friday, September 23, 2005 9:24 PM
To: RBG7-L Mailing List
Subject: [RBG7-L] - RE: Refreshing multi table screens

Thanks Dawn.

The top table displays one row (a work order) and the bottom region displays multiple rows (one or more employees).

I tried Nextrow in the EEP and then I delete the rows in the two tables in the previous row. I thought if I was no longer "looking at" the rows being deleted that the Refresh might work. (If you don't Refresh, you get the invalid cursor error.) I'll play with it a bit more.

Thanks Again,

Dennis
*****


At 04:21 PM 9/23/2005, you wrote:
Dennis,
Are you displaying your rows in regions or a single rows on a form?
Dawn


From: Dennis Fleming [mailto:[EMAIL PROTECTED] ]
Sent: Friday, September 23, 2005 3:22 PM
To: RBG7-L Mailing List
Subject: [RBG7-L] - RE: Refreshing multi table screens

Thanks Dawn,

I think I'm closer. Maybe a little more trial and error.
Current code in EEP button is:
...
INSERT INTO oldtableA SELECT ALL FROM tableA WHERE tk_nbr = .tknbr
INSERT INTO oldtableB SELECT ALL FROM tableB WHERE tk_nbr = .tknbr
...
DELETE ROWS FROM tableA WHERE tk_nbr = .tknbr
PROPERTY TABLE tableA "REFRESH"
DELETE ROWS FROM tableB WHERE tk_nbr = .tknbr
PROPERTY TABLE tableB "REFRESH"

The Property Edit you mentioned doesn't seem to make a difference other than asking if I want to save the row(s). The action I am look for is the same is if you Deleted a row in tableA (which is set to delete the corresponding rows in tableB) and then go to the next row in tableA.

Dennis
****

At 01:01 PM 9/23/2005, you wrote:
Dennis,
I have a form that is refreshing multiple tables, using the property
command and it works without nextrow/prevrow.  Though before the
"editing" of the data in the slave table, I had to use the
property...edit command first.  (I do remember initially, I did the
nextrow/prevrow thing which also worked, but caused the screen to
flicker.)

Example:

PROPERTY TABLE slavetablename 'EDIT'
-do other stuff here, like inserting, updating, deleting

PROPERTY TABLE slavetablename 'REFRESH'

I'm not sure if that's what you're doing already.  You don't say how
you're trying to refresh the tables.

Dawn


-----Original Message-----
From: Dennis Fleming [mailto:[EMAIL PROTECTED] ]
Sent: Friday, September 23, 2005 12:18 PM
To: RBG7-L Mailing List
Subject: [RBG7-L] - Refreshing multi table screens

RB7.1 FRC14

On a two table form, the user can click on a button to "closed the work
order" and the PK row and FK row(s) are added to a "closed table",
deleted from the screen form the are viewing, and the next PK row is
displayed.
Refreshing the PK and FK tables in the EEP, only refreshes the PK
portion of the form. Using Nextrow/Prevrow will cause a cursor error
message. I have had a chance to "play" with this a lot the last few days
but still coming up short.

Note: By having the R> window behind my app when it is running has
really help clear up a number of bugs. For example, if you have an EEP
which is run when you Save a Row... don't put Saverow in that EEP!

TIA,

Dennis
*****
Dennis Fleming
IISCO
http://www.TheBestCMMS.com
Phone: 570 775-7593
Mobile: 570 351-5290

Dennis Fleming
IISCO
http://www.TheBestCMMS.com
Phone: 570 775-7593
Mobile: 570 351-5290

Dennis Fleming
IISCO
http://www.TheBestCMMS.com
Phone: 570 775-7593
Mobile: 570 351-5290

Reply via email to