Are you getting Server.CreateObject failed while checking permissions? Access is denied to this object error or some other permission error? These problems occur mostly (99%) with Windows 2000 or Windows XP Server. They are documented (and several solutions are presented) in Microsoft Knowledge Base article Q259725. Basically, after being severely critisized for lack of security in Windows NT, they really went overboard with it in Windows 2000 and later. For instance, out of the box, you can't debug ActiveX DLLs in Visual Basic 6. You can run them fine, but you can't debug them.
Why does this occur? Because when you debug an ActiveX DLL which is being called from IIS, you are doing so with the IUSR_machinename account. Now, IUSR_machinename account has permissions to run ActiveX DLL, but when you are debugging in the VB IDE, you are really running VB6.EXE which is actually an ActiveX EXE. IUSR_machinename account has no permissions to run ActiveX EXEs. Permissions for ActiveX EXEs are set through DCOM.
The knowledge base article presents 2 solutions. First solution is a long-term resolution which will allow you to debug any ActiveX DLLs. Second solution will only apply to your current problem. On top of that if your web server is available to the public - it will make everyone log on(!!!), so try the first solution and see if that resolves your problem.
I actually have an even better and an easier solution to this problem. Simply run your app under an account that has admin rights. What? You are worried about security? This is your development PC, so who cares about security.
Once you get past the initial amazement :), you'll want to speed up your development even further. In my work, I have to constantly crank out various lists of information, often in a listbox form. So I wrote a control that almost fully emulates the standard VB listbox and adds a Render method that spits out the list in the HTML listbox form. Check it out here.
Drawbacks A reader emailed me complaining that I haven't listed any of the drawbacks of this method. And as with anything, there are tradeoffs to make in life, so there are some drawbacks. I will list them, each with a quick explanation.
Performance This method yields pretty good performance. Most of the time it is better than ASP or ASP plus some COM Objects. However, don't expect to write the next Yahoo site because the performance will not stand up to it. On a standard server (512 MB RAM, fast HD, PIII 700Mhz or so), you will get pretty good performance with around 30 concurrent (by concurrent I mean people simultaneously requesting a page) connections. The overhead of simultaneously retrieving 30 different HTML templates from the hard drive (or even from RAM once it becomes cached) is enough to bog down the performance. However, once you reach a milestone where you have 30 concurrent users, you should scale out (i.e. get more servers).
Security Another common complaint is that the method exposes class names and that somehow it is dangerous. While I don't consider it a risk, if it makes you uncomfortable, simply mask the class names by changing them in the ASP file. In other words, if the class name is EmployeeDelete, have the URL pointing to exec.asp?cls=Employee&CMD=Delete. In the ASP file, you would have to catch this (using the QueryString collection) and do a Server.CreateObject on QueryString("cls") & QueryString("CMD").
Hosting Jason (email@example.com) mentioned this problem and it truly is the only one that actually impedes this method. If you are hosting your application with a hosting provider, chances are they won't allow you to register DLLs on their box. This is not a problem if you are writing your apps for the intranet or for corporations that host their own web sites. So what are you choices if you are in a hosting situation? Well, you can co-locate your own box with the hosting provider. That's more expensive, but the only solution I can think of.