Microsoft Access Without Jet
Why Current Attempts To Evolve Access Without Jet Lack Lustre
The whole issue can get quite emotionally charged because evolving MicrosoftAccess without the JetDatabaseEngine is not a simple matter of technology, it drastically affects the livelihood, joie de vivre of some very passionate people.
Since Jet is intertwined with the .mdb format, let's discuss the new format - the .adp - which has no Jet. After some development experience with .adp, here are some points of concern:
- Jet always tried to make Forms editable and Reports filterable. Even in the grey areas where Primary Keys or relationships might have at first glance, prevented this. Without Jet, the .adp lets you "fall to the floor" - there is no high level transparent abstraction - much too easily Forms record edits, filters etc... don't work anymore. Yes, there are ServerFilters but they don't work with Stored Procedures etc...
- In recognition of such problems in Access 2000, Access 2002 has a thing called CDM (ClientDataManager). This resolves some issues but only a few of them.
- The problem is that Jet had AccessQueries - full stop. MicrosoftSqlServer has traditional things like T-SqlViews, T-SqlStoredProcedures, T-SQLFunctions. That means the architecture is more complex (more powerful). The End Result is that the Forms which hid all the nuances in .mdb are now unable to in .adp.
To understand about some of these breaks in transparency read: "Microsoft Access Projects with Microsoft SQL Server" by Microsoft Press (there is a story about why "Microsoft" has to be in every name
-- AnandaSim
But See InspectEvalFileFormat
--PhlIp
To each, his own
But seriously, the Dictionary object is also available in VisualBasicForApplications, VisualBasic or anything that can consume the VbScript - ScriptingDictionary object. This is equivalent to the Perl associative array and real cool.
Can VB inspect and eval? I don't know. You might want to check out WhyVisualBasic or CategoryVisualBasic .