True, but the other long version is safer in the long run. That is my opinion based on long experience.
Dennis McGrath Software Developer QMI Security Solutions 1661 Glenlake Ave Itasca IL 60143 630-980-8461 [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MikeB Sent: Wednesday, April 02, 2014 5:05 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Scrolling Region This shorter version works too... CREATE VIEW MyFormView AS SELECT + PrimKeyColumn, DataColumn LastUpdated as LastUpdatedT1 FROM MyTable > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Bill > Downall > Sent: Wednesday, April 02, 2014 2:31 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - Re: Scrolling Region > > Mathew, > > That feature of R:BASE goes back a long way -- to a time before R:BASE > had implemented SQL Primary Keys and Foreign Keys. For R:BASE, if you > name a column the same in two tables, an R:BASE Form will assume that > the same-named columns are linking columns, and look for matching > values. just like PKs and FKs. > > There is a way around it, through update-able views. Create a view on > one of the tables that renames the column that has the same name but is > not a linking column. Be sure the view has no features that would make > it a non-updateable view (no GROUP BY, no ORDER BY, no Aggregate > functions (SUM, MIN, MAX, COUNT, AVG). Then use that view in the form > instead of its underlying table. > > CREATE VIEW MyFormView + > ( PrimKeyColumn, DataColumn, LastUpdatedT1 ) + AS SELECT + > PrimKeyColumn, DataColumn LastUpdated + FROM MyTable > > > On Wed, Apr 2, 2014 at 2:10 PM, Matthew Brock > <[email protected]> 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. > > Thanks, > Matthew D. Brock > > > > ________________________________ > > 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 <http://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! > -- > > > > > > > >
