In my A/P register, the header would've contained the TransID, PayeeID,
TransDate.
The first two would've been PK in any master/detail section.
I decided I could give up the real estate of the TransDate being replicated
on each line of data to drop the first table.
When an item is paid, a check number field in the table is updated which
ties the item back to the APCheckReg, making it easy for me to drill down to
details for the check.
I can imagine many other scenarios where this may not work, but sometimes we
tend to overthink stuff a bit because it just looks too simple to be good.
----- Original Message -----
From: "William Stacy" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Friday, December 17, 2010 3:49 PM
Subject: [RBASE-L] - Re: One table vs. two tables.
To me it would depend on how often you do the evaluations. if only once a
year, then it doesn't matter much. if every month, that could mean
entering the header info as much as 700x12 times per year. what a waste of
time!
plus, i would think you'd have each piece of equip elsewhere in the database
with such things as when purchased/cost/location/etc. all of those things
plus it's id # should reside in the first table.
On Thu, Dec 16, 2010 at 11:40 AM, Javier Valencia <
[email protected]> wrote:
I have an application where an equipment evaluation is generated
periodically for app. 700 pieces of equipment. I can set up the data
structure as on or two tables.
One table approach:
Table Evaluation
EvalID
EvalDesc
EvalDate
Other data columns
========================
Two table approach:
Table EvaluationDesc
EvalID
EvalDesc
EvalDate
EvaluationData
EvalID
Other data columns
========================
The two table approach does conform to the “no duplication of data”
principle but it requires a two table form and reports would need to use
either a view or a sub-report and more maintenance. The one table approach
does duplicate data, but maintenance is much simpler; i.e. one table forms
and reports, backups, data transfer.
I am inclined to go with the one table approach as the increase in storage
(no longer an issue) is more than offset by the additional effort needed
to
work with two tables. Any thoughts?
Javier,
Javier Valencia, PE
913-829-0888 Office
913-915-3137 Cell
913-649-2904 Fax
[email protected]
------------------------------
*From:* [email protected] [mailto:[email protected]] *On Behalf Of *Jim
Belisle
*Sent:* Thursday, December 16, 2010 12:32 PM
*To:* RBASE-L Mailing List
*Subject:* [RBASE-L] - Re: DB grid
Dennis, Larry,
I went with the var list view and it worked just fine.
Of course I would like to find out what was wrong with the DBGrid but
maybe
some other day.
Thanks for the suggestion.
James Belisle
------------------------------
*From:* [email protected] [mailto:[email protected]] *On Behalf Of *Dennis
McGrath
*Sent:* Thursday, December 16, 2010 11:30 AM
*To:* RBASE-L Mailing List
*Subject:* [RBASE-L] - Re: DB grid
I prefer a variable lookup listview for view only purposes. Much easier to
implement and use.
Dennis
------------------------------
*From:* [email protected] [mailto:[email protected]] *On Behalf Of *
[email protected]
*Sent:* Thursday, December 16, 2010 11:17 AM
*To:* RBASE-L Mailing List
*Subject:* [RBASE-L] - Re: DB grid
Have you tried creating a new form with just the DBGrid on it? That would
show whether the problem is with the Grid itself, or perhaps with the
links
to the master table.
Karen
Even when I added the DBGRID itself, no information showed up on the
grid. The common column is Control#.
--
William Stacy, O.D.
Please visit my website by clicking on :
http://www.folsomeye.net
