If encryption were implemented, and the obscurity of the meaning of the data
and it's relations were important, I would agree with you (eg personal info
security). But this brings in complications with maintence that I don't
think most people care to get into. Person A designs a system in order to
prevent Person B from interpreting it. Person A gets fired, or is no longer
around, and nobody understands it anymore. The documentation of the project
would need to be flawless in order for a newcomer to take over (I'm sure
that is really common too). Sometimes I think that if security is that
important, Access is not the tool to build with.
"Peter Miller" <pmiller@pksolutions.com> wrote in message
news:bacl1096k2v9gtsee2e9jrb8k4g7bis8t7@4ax.com...[color=blue]
>
> Mike,
>
> On Fri, 30 Jan 2004 14:35:35 -0500, "Mike Storr"
> <nobody@somewhere.con> wrote in comp.databases.ms-access:
>[color=green]
> >I don't see how relationships are that important to protect...[/color]
>
> In general, of course, you're right.
>
> But I suspect that as part of an effort to protect the db, the OP has
> used generic field and table names. For example, tblInvoice,
> tblInvoiceDetail and tblSalesperson are instead named tblA, tblB, tblC
> etc. and have fields (a,b,c,d,e,f), (a,b,c,d) and (a,b,c).
> Relationships show that tblA.e ties to tblC.c and tblA.c ties to
> tblB.b. Obfuscation is pretty limited in effectiveness, especially if
> relationships are visible. By preventing relationships from being
> seen, it's not clear with the range of values in tblA.c being from
> 1..25 which other table it may relate to.
>
> I'm not advocating such a setup. In fact, i think it violates all
> sorts of good design principles. But its effectiveness is most
> seriously hampered by relationships being visible (well, among other
> things), so perhaps that's why the OP wants to protect relationships.
>
> I just thought I'd throw it out there as a possible implementation
> where something that normally has little value in terms of a security
> mechanism might actually take on more prominence under a specialized
> case.
>
> Peter Miller
> __________________________________________________ __________
> PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
> Free quotes, Guaranteed lowest prices and best results
>
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051[/color]
