At 02:10 PM 4/2/2014, Matthew Brock wrote:
That was it. There was a column in each called LastUpdate. I dont see
why that should affect getting data based off of keys, but thanks.
This is what I emphasized in my original reply.
----
Common Column Names with Matching Data is the key.
So, in your specific situation, using the Data Browser, take a look at
the list of columns in Invoice_Header table. Then, take a look at the
list of all columns in Invoice_Trans table. Find the common columns
and the matching data.
That simple exercise should provide you with some blue's clues ...
---
Very Best R:egards,
Razzak
From: Karen Tellef <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Wednesday, April 2, 2014 12:43 PM
Subject: [RBASE-L] - Re: Scrolling Region
What we're saying is that even though you have a good PK/FK match,
carefully compare every column name between the 2 tables. You might
have another column that exists in both tables but does not have the
same data in it. Just today I debugged a form created by someone
else who said the same thing "the detail data won't show up". The
first thing I did was compare the column listing of both
tables. Sure enough, there was a column called Status in each of
the tables, and there was different data in them so RBase would not
"link" both tables. And remember, nulls are never a link. What I
do in those instances is to create a single-table view of the detail
table, renaming Status to Status2, and it now shows up and is editable!
Karen
-----Original Message-----
From: Matthew Brock <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Wed, Apr 2, 2014 12:31 pm
Subject: [RBASE-L] - Re: Scrolling Region
The names look identical.
The form is set up as a Many-to-Many Relationship
Tables are basically set up as follows
Item_Master
Item_Number PK
Item_desc
....
Invoice_Header
Invoice_Number PK
.....
Invoice_Trans
Invoice_Number FK*
Item_Number FK
...
Thanks,
Matthew D. Brock
From: A. Razzak Memon <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Wednesday, April 2, 2014 11:52 AM
Subject: [RBASE-L] - Re: Scrolling Region
At 12:27 PM 4/2/2014, Matthew Brock wrote:
>I am converting some forms over and a few of them have a scrolling Region.
>The data in the region never gets read in when you do an edit. Is there
>some field that needs to be set for this?
>
>The form is being used as a transaction for a customer. so the top of the
>form is from the invoice_header table.
>This has information like cust_number, invoice_#, etc..
>The scrolling region has data like item number, item description, quantity,
>total, etc. It is read from table invoice_trans which is associated with
>invoice_header by the invoice_#.
>
>It is like it doesn't know what the invoice_# is to grab the data for in
>the invoice_trans table.
>
>Can someone help?
Using a multi-table form having One-to-Many table relations, the link
between Master/Slave table(s) is established by using the "common column
names with matching data".
Common Column Names with Matching Data is the key.
So, in your specific situation, using the Data Browser, take a look at
the list of columns in Invoice_Header table. Then, take a look at the
list of all columns in Invoice_Trans table. Find the common columns
and the matching data.
That simple exercise should provide you with some blue's clues ...
If installed, you may also use the R:Column Analyzer Plugin 9.5 to
visually display and analyze One-to-Many or Many-to-Many relationship
between tables.
Database Explorer | Main Menu | Utilities | Plugins ...
Very Best R:egards,
Razzak.
www.rbase.com
www.facebook.com/rbase
--
31 years of continuous innovation!
16 Years of R:BASE Technologies, Inc. making R:BASE what it is today!
--
