Richard,
I'd like to push back and say, no I don't hate Access. It is a very useful
tool that I frequently use myself. Where you and I diverge is on its
suitability for use in part 11 systems.
While I agree with you that good tools will not guarantee a suitable
product, on the flip side, I do not agree with you that poor tools can
be use to build a suitable product, regardless of the development
methodology. Wrapping code around an inferior core to address
FUNDIMENTAL shortcomings of a tool (Jet in this case) is not an
appropriate solution.
Yes, everyone agrees that the FDA doesn't care if you use VB, C++,
Jet, Oracle. What they do care about is whether or not it is validated.
This means that us, the users, must show it is reliable, secure, and part
11 compliant. Where you and I seem to disagree is on those
evaluations - are VB/VBA and Jet reliable, secure, and compliant. I
maintain No, they are neither stable nor secure enough.
I stated earlier that I'm not going to go bullet by bullet how Jet doesn't
measure up, besides you know the security, locking, and auditing
deficiencies as well as I do. You said as much when you stated in an
earlier post that neither Access nor Jet were compliant out of the
box. Again, where we diverge is the resolution to this. You maintain
that using a good development methodology to generate code you
will build on top of Jet will correct these deficiencies. I maintain that
this is poor implementation, and that key functionality needs to exist
as part of the core DB engine. Otherwise, once someone is past your
front end (as either an admin or because of a crash or lapse in user
integrity) you've lost all your part 11 enforcements. If that
functionality is part of the core DB engine, then loss/bypass of the
front end doesn't jeopardize the integrity of the data.
As an example, part 11 (mainly from the preamble p13460 and
11.300d) requires that for a system using user ID/passwords to be
able to detect and log attempted unauthorized access to the records
and system. Because of the nature of a Jet database, anyone trying to
get at the database bypassing the front end (be it either direct file
access, ODBC calls, or Access security hacks) will not be tracked by
the database. Can network security log these attempts? Somewhat,
but not really to the appropriate extent. Also you've just added an
immense amount of unnecessary complexity to the system to do
something that is not part of its core functionality. It is significantly
more robust, simple, and coherent to have complete security managed
from a single server based system - like SQL/Oracle/DB2 offer.
I can hear the cries from the group now, "We aren't expected to make
our systems hacker proof, just secure enough for trained users!" I'm
not stating that we need to be %100 hacker proof, but 11.300d and
the preamble make it pretty clear that we are supposed to be able to
log, alarm, and respond to ANY unauthorized attempts, and it doesn't
differentiate between simple attempts from untrained users and more
persistent attempts from users that have had a lapse in judgement.
Finally, I still maintain that when validating COTS we HAVE to
remain inside of the constraints that the vendor supplies, otherwise
we are not being consistent. We can't play the "COTS card" when we
feel it saves us work, then say it doesn't matter when it doesn't suit
our needs. When Microsoft says it is not appropriate to use Jet for a
secure robust environment, we have to defer to them - they hold the
source code and code level tests. Access and Jet were designed from
day one for desktop databases - their very file structure speaks to this.
It is inappropriate to try and extend it past that base when there are
already more suitable tools in place that offer a much more complete
solution right off the shelf.
Regards,
Jim Elliott
Wyeth-Lederle Vaccines
RapidEye@Bigfoot.com
|