Well, there are a few reasons...<br>
VB of course is the obvious choice for security reasons. But I can still set Access security to keep the majority of casual and even wannabe serious-hackers out. On a mission-critical app I would not use Access as a front end. That said, I think Access Forms have a better Event model (or maybe just more familiar) than VB and in general Access is much easier and faster to develop in. Also, I believe access has a far superior report writer than Crysal, which is what VB would most likely use, and in so many apps, reporting is not only crucial, sometimes it's everything.<br>
<br>
Moving on, my apps typically will end up a mix, ie, some bound, some unbound based on the use, but also I take static data tables and keep in in local mdb tables--ie, a States table, which hasn't changed since 1959 and won't soon, is a good canditate to keep local. On all forms that use it, we don't have to hit oracle for a list of 50 states to load a combo box every time the form opens. That's an obvious example, but doing an analysis of the data and it's frequency of updates can mark many tables to mirror, saving alot of bandwidth, ie, in one app I had a Parts table that was several thousand records, and was only updated weekly via an import process of new parts, changes, etc--(no direct user updates). <br>
<br>
I keep a table called DirtyLocalTables On oracle that has a list of locally mirrored tables, with flags that are set on triggers in the Server copy of these mirrored tables. Upon opening Access it's read and any tables with updates/deletes/additions are refreshed accordingly. This all would be more difficult with VB--and an .mdb would still be needed anyway. So, I guess you could call part of it lazyness
, but seriously, there are lots of other little things (better, easier combo boxes, for another) that add up to make Access a good choice--even if you're going the unbound C/S route.<br>
--Jim
