[AccessD] Hiding Back End Design

Good point.

An backend whose design is 'open' can be a selling point. It helps avoid
YAID syndrome - "Yet Another Island of Data". Most companies can recognize
the benefits of integrating their data - CAD/Design with Bill of Materials,
BOM with Purchasing, etc. but are stymied by the 'black box' backends of the
various programs they use for each task. Few companies are in the position
to 'sweep it all out' and start from scratch, so they look for new software
piecemeal, adding functionality as needs require.

The problem is that the efficiencies gained by the new software are often
mitigated by lack of bridges to the other islands of data surrounding it.
This requires workers to do double entry (if they bother at all), use
paper-based solutions, create ad-hoc merges of data in Excel, etc. in an
attempt to get the unified picture they require to do their jobs.

In our company, the preference has been many times to build in-house
solutions, that are acknowledged to be less fully-featured than commercial
alternatives, in order to gain the benefits of integration with the larger
data archipelago.

So, instead of viewing the 'openness' of a data schema as a problem, perhaps
it should be seen as an opportunity. Document your schema nicely using a
case tool. Make it freely available to your customers. It could be the start
of realizing a new revenue stream alongside that generated by your
standalone program, namely, integration services.

-Ken

-----Original Message-----
From: Gustav Brock [mailto:gustav at cactus.dk]
Sent: Monday, June 21, 2004 1:02 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Hiding Back End Design


Hi Rocky

No, you cannot open or attach tables from the BE without the correct
password. But as stated from several already, you can google up at
least three password crackers.

Next step would be Access security as mentioned by Drew, and the next
would be to apply field encryption which is a major step.

By why not turn it completely around: make the design open and
documented as "this is the way to build a database for an application
like this"? Then you are the master and everyone else is the
replicant - following the "Rocky" standard. Personally, I think the
time for proprietary systems has passed - customers need systems they
can drag data from to be used elsewhere.

Also, I really doubt someone can figure out the intelligence of your
app just by watching the table design. One can watch what is going on
when data have been entered or updated but not _how_, and if someone
can figure it out, he will already know how to build a similar app
without knowing your table design.

/gustav