Re: Force a limit to number of rows

Jamie

Perhaps you misinterpreted my statement.

I was pointing out that Access forms are for displaying (add/edit/...) data,
while Access tables are for storing data.

Working directly in the tables (i.e., data entry) is not the preferred
approach if you want to offer an application that folks can use without
undergoing serious Access training.

JOPO (just one person's opinion), like yours

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Jamie Collins" <jamiecollins@xxxxxxxxxx> wrote in message
news:36f7c987-fba6-46ab-84e5-595898c240de@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 16, 3:49 pm, "Jeff Boyce" <nonse...@xxxxxxxxxxxx> wrote:
Jamie's approach...
requires a bit more technical approach...
so you (or your
successor) may have trouble figuring out what was done.

Another approach, perhaps less technical, but perhaps more
"discoverable"...

Interesting point. I'm no Access interface expert, so I ask myself,
"What would Allen Browne do?" See his article about SET NULL
referential actions:

http://allenbrowne.com/ser-64.html

[Quote]

But what if someone else needs to rebuild the database at some stage?
Since the interface cannot show them that cascade-to-null relations
are in force, they may recreate the tables and have no idea that your
application relies on this type of cascade. You need a way to document
this, and ideally it should be visible in the Relationships window.

Create a table purely for documentation. The table will never hold
records. To ensure it shows in the Relationships window, create a
relation to other tables, so it is not only saved in the Relationships
view now, but shows up when the Show All Relationships button is
clicked.

The field names can be anything, but since the goal is to catch
attention, you might create a sentence using odd names reserved words:

Field Name Data Type Description
* * * WARNING * * * Text Informational only: no data.
Cascade Text
to Text
Null Text
Relations Text
Exist Text
On Text
Products Text
And Text
Categories Text
Id Number Primary key

[Unquote]

I really can't say whether that's a good idea or not (personally, I
advocate good documentation *external* to the database itself e.g. the
data dictionary) but my point is that inherent lack of visibility (or
"discoverability" if you will) in the Access interface doesn't faze
Allen Browne a.k.a. "The Access MPV's Access MPV" :)

Another approach, perhaps less technical, but perhaps more "discoverable"
would be to use a form to mediate data entry (this is the preferred
method).

*Your* preference, maybe <g>. I prefer (and many other professionals
do) to enforce simple data rules in the database itself using table
constraints, rather than maintaining the same logic in every element
of every application that will ever access the data. Just as you think
in terms of a successor developer inheriting the application, I think
in terms of a successor application inheriting the database.

Jamie.

--




.