Access provider: `Jet OLEDB:Database Password` not picked up

[jeffreyheping]

---

Hi Pieter,

First a small note of appreciation: I just spent some time running a fairly gnarly legacy app on ASPPY, and the completion level honestly surprised me. The VM, the ASP object model, ADODB, Global.asa — it all hangs together in a way I have not seen from a pure-Python VBScript implementation. And because it's Python, I can introspect anything I want with a debugger. No recompile, no native symbols, no "where is the source." That alone makes ASPPY a pleasure to dig into compared to wrestling with a black-box runtime.

One concrete issue I ran into, on a password-protected Access database.

Classic ASP apps often write the password into the OLE DB connection string with the property name Jet OLEDB:Database Password=.... This is the standard, documented form — see practically any old sample using Microsoft.Jet.OLEDB.4.0.

ASPPY classifies the connection correctly as access, but when building the underlying ODBC connection string in ASPPY/adodb.py (around the _AccessProviderAdapter.open method), it only looks for the keys password and pwd. The Jet-specific jet oledb:database password is silently dropped, so the ODBC driver is opened without a password and the connection fails.

My test case:

' core/db.asp
If DB_TYPE = "access" Then
    connStr = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath(DBaccess_SOURCE)
    If DBaccess_PWD <> "" Then
        connStr = connStr & "; Jet OLEDB:Database Password=" & DBaccess_PWD
    End If
End If
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open connStr

With a non-empty DBaccess_PWD, this fails; with an empty password it works. The fix is to recognize the Jet-specific attribute name when extracting the password. One-line change:

pwd = _pick_attr(info.attrs, 'jet oledb:database password', 'password', 'pwd')

I would love to send a small PR with this and a test if you're open to it.

Thanks again for keeping this technology alive — and for doing it in a language that is so approachable to read and extend. ASPPY is doing genuinely important work for the people who still care about these applications. I will be watching the project closely.

Have a great week.

Jeffrey

[PieterCooreman]

Hello Jeffrey, thanks for reporting this issue! I have indeed never tested password protected Access databases. From day 1 I used Sqlite databases in ASPPY. Access databases can grow up to 2GB. SQLite databases can grown into 100's of terrabytes.

I will look into this issue and report back.

Pieter

[jeffreyheping]

Thanks for sharing the design rationale — it's helpful to understand the background.

I'd like to add one perspective: focusing on Access isn't just about migrating legacy apps. It also serves an important role as a reference implementation — a baseline for cross-platform behavioral consistency.

Because SQLite is essentially "free-form" and there's no built-in SQLite story on IIS (if there's a recommended setup, I'd genuinely love to know), having Access as a stable reference helps define what "ASP Classic compatible" actually means. Without that anchor, it's hard to know whether ASPPY's behavior truly matches what developers expect from the original runtime.

Thanks again for ASPPY — having a Python-based, debuggable ASP runtime is genuinely valuable for the community.

[PieterCooreman]

I use the Python webserver (used by ASPPY) indeed. But I use IIS to deal with bindings and SSL certificates, as I run a Windows Server for many sites already. Here's the web.config for https://flowdent.be, a site running on ASPPY (served by IIS, routed to the Python webserver). All traffic is internally routed to port 8086. The Python webserver for flowdent.be listens to that port. I run 16 ASPPY sites this way, each on a different port, each with a different Python process, each with a different IIS entry. It's a bit of a complex setup, but it works. I manage all Python processes with a tool named NSSM (https://github.com/kirillkovalenko/nssm). I therefore built a little Python tool that lists all Python processes and the according ASPPY websites. To keep things manageable I created a .bat file that lists all Python processes, and lets me restart, stop or remove them:

Below the web.config for flowdent.be

Other sites I host - purely on ASPPY/Python on an IIS SSL-layer:
https://aspgamer.quickersite.com
https://lifeadmin.be
https://nomenclatuur.flowdent.be

and some others... Stability is 100%. In the past 4 months, I haven't had 1 second of downtime of any of my ASPPY-based ASP websites. That's promising I think.

[jeffreyheping]

Hi Pieter,

Honestly, my mind is a bit blown. I totally expected something like ASPPY to be built in C, C++ Rust and Go. The idea of using Python to create a stable, production-ready runtime for a classic language like VBScript is seriously impressive, and it completely challenges my own assumptions about what Python can be used for.

[PieterCooreman]

I noticed GitHub removed the web.config. I replaced it with a screenshot. With this web.condig, ALL traffic to flowdent.be is forwarded to port 8086. There is a go between, where you only forward *.asp files to Python, and use IIS to serve static files, .NET and/or PHP.

[PieterCooreman]

hi Jeffrey, I choose to let ASPPY default to SQLite because Python ships with the sqlite3 module anyway. SQLite requires zero configuration when used in Python. Also, SQLite is a file-based solution, pretty much like Access. Finally, with free tools like https://sqlitebrowser.org/, you can easily browse tables and data in a SQLite database. Finally, unlike Access, SQLite handles multiple read requests simultaneously.

ASPPY ships with an Access-to-SQLite converter .py script. Ever since I started using SQLite in ASPPY, I never looked back at Access. Also, SQLite is free and can be used with other web frameworks like Django and Ruby. SQLite is simply the better option for any web app.

Nevertheless, I will look into the password-protected Access database issue that you reported. This will only require a minor fix I guess. Thanks again!

[jeffreyheping]

Agreed, SQLite is far more advanced than Access. However, as an ASP programmer trying out ASPpy for the first time, he will very likely pull out a dusty set of CRUD code to test it—and behind that code, there’s a good chance it’s backed by an Access database. If he can discover right away that everything runs smoothly, that would give him immense confidence to keep exploring and experimenting.

Take me back then, for example: I tested AxonASP exactly this way, and found that it actually worked! Although I later ran into various issues, the feeling of success from a simple CRUD test made the system feel completely usable.

That’s exactly why I’ve been pushing you to fix Access support. Not for actual "production use," but just so it "can be used." It’s all about the user experience.
❤️😄

[PieterCooreman]

Jeffrey, I totally agree. It would be very nice to welcome back old ASP coders and provide them with a 100% 1-on-1 compatible ASP Classic/VBScript/JScript environment. Be aware though that 99% of the old legacy ASPClassic code is most likely facing charset-encoding issues and also suffers from SQLi - XSS - CSRF issues. It's simply not a good idea to revive these scripts or apps, at least not without a severe security-audit.

On top of that, there are a couple of party crashers. The OLEDB drivers for Access and SQL Server are one of them. Even MicroSoft did not rewrite them for 64bit Windows-OS. The wscript.shell abilities are another one. And finally the vast collection of 3rd party COM classes/components that were developed/redistributed/sold over the past 30 years. The latter can be brought down to mainly PDF, ZIP and JPEG manipulation classes that are both covered in AxonASP and ASPPY.

I have a suggestion. AxonASP relies on Go, ASPPY relies on Python. What are you waiting for to create your own flavor of ASP Classic compiler in yet another technical stack? Node.js/TypeScript? Rust? .NET (C#)? That would be just a great addition and I would be willing to help you with that.

I have always used the best cloud AI models available. ASPPY is 100% built by Claude Opus 4.5, 4.6, 4.8 and the changes I made today are done by Claude Fable. Today, models like Kimi K3 may be much cheaper and can return very decent results as well.

Let me know what you think.