Re: A philosophical newbie issue: catch redundant errors via relationships or programmically?

raylopez99 wrote:
> mAsterdam wrote:

>> raylopez99 wrote:
...

>>> Table Bank has a primary key comprising: An account number that is
>>> unique to every person--hereinafter "Bank"
>> 
>> Why not call it 'Persons' ...?

Names matter more than many people care to realize.

When somebody else (or you after a few years) revisits your application, trying to find how the components are intended to work together, the names should provide clues, not riddles. The data part has the longest life-expectancy. Extra care should be taken.

...

> So all is well.

Good.

> Access 2003 is quirky,
> as some metadata apparently resides in the engine that has to be
> flushed out it seems (even in this simple example I had to open and
> close a few files to flush out the data).

Caches can hit you hard, not just in Access :-(

> Also my problem may have
> been I changed the schema as you call it "mid-stream" and some old
> data was in the dB from a prior schema, and perhaps it caused Access
> to choke. In any event, for my particular prior problem I
> programically inserted a data trap to catch redundancies and alert the
> user, so all is well.

As I said before in this thread:
Good to warn your users they are
about to violate a constraint,
not good to guard your data in a UI.

>>> LOL.  Access is great for rapid coding at the GUI level--you should
>>> see what I've come up with in only a few days, but it's kludgey trying
>>> to debug stuff.

>> It is a matter of focus and scale. Using your editor
>> to edit textfiles with data is one end of the scale.
>> While it is obviously not a good way to protect your data
>> against mistakes, it suffices for a lot of my
>> personal data.

And, the way you seem to use it, to only one single developer.

--
What you see depends on where you stand.