It brings me to the question: Is standard Access - the way it is developped - the ONLY way to work with?
Or are there other ways for more functionality but different "cosmetics"?
If you have something suitable, even an old copy of VB6, that can generate machine code and can make a callable entry point to a SUB or FUNCTION, you can create your own "reference" library, using Access and/or VBA as scaffolding. That could lead to different functionality or cosmetics. But in the final analysis, if Access is your base, what you do is going to have to look like something that Access itself could have done. In a sense, this is the old conundrum of "If what you have is a hammer, everything needs to capable of being nailed." (Or percussively adjusted.)
If you write something in another environment, you have to be able to call appropriate tools to modify Access native data or use ODBC methods for SQL Server stuff. Because as along as the "standard tools" still are involved - in this case, Access or SQL Server - you can't make it look totally like something else. If it was supposed to be a database, it has to look like a database at the end of the day.
If you try something web-based, the ugliest issue is calling functions from a web page. Access no longer handles ADP, so that is out of the window. If you tried to download some program as part of a web page, your anti-virus or internet security package would screech like a banshee about that download attempt.
So I guess the answer is, within limits, a "definite MAYBE, but don't go too far astray" on different functionality and cosmetics.
