Lap,
Sounds like it's up to you to do what you want with it. If it contains
important codes or reference data, I say leave it. But if it's continually
dropped and recreated, I would wonder about how the data is used, who, how
often, etc.
I generally split tables up like this:
back-end
-------------------
TRANS - transaction tables (ie items rented)
REF - reference tables (lists of categories, codes, states, cities, etc
enforced on the transaction tables)
XREF - cross-reference tables (various xref between reference tables)
front-end
-------------------
TEMP tables (data summaries used for reports, etc.)
WORK tables or SYS tables (list of reports on a report menu, search
categories, things used with coding and processing, etc.)
(note: I sometimes place WORK tables in a separate db, or even in the
back-end)
"Lapchien" <bl**@blar.tv> wrote in message
news:10*************@ananke.eclipse.net.uk...
When it's created (currently in the access BE) users have a link from
their FE, nothing fancy, just to lookup. The summaries it contains are just
currency transactions, basic 'sum' query expressions.
--
Thanks,
Chris
cc****@NOSPAMeclipse.co.uk
"DFS" <no******@nospam.com> wrote in message
news:vt************@corp.supernews.com... "Lapchien" <bl**@blar.tv> wrote in message
news:10**************@ananke.eclipse.net.uk... A user has a make table query, basically it does some summing and creates a 'summary' table. I'd like to get rid of it (it's the last one in the
access back-end) and use pure sql. Is the same thing easy enough to
accomplish in sql or would you still need to make the table in the FE and then
update the (same) table in sql..?
Depends on how it's used, what kinds of summaries it contains, if FE
users have links stored to this summary table, etc.
--
Thanks,
Lap
