Brian has that one correct - you most likely have a naming problem for your DLL , or your SqlDataProvider type.  You can step through the code code to see the point where it is trying to call 'loadAssembly' (or whatever the call is, I forget) with the typename.  Then work out what that type name is and rename your assembly.

I prefer PA dll module development because it's a self contained application, you dont' need the entire DNN site loaded into VS to code, and it's easier to source control.  It's also easier to develop for different DNN Version by sending the compiled DLL to different test installs.  And finally, it's easier to load into unit testing suites when it's a simple DLL.

Thanks Brian... that was the problem. In my DataProvider.vb file, I had to change the following line in the Private Shared Sub CreateProvider() sub:

objProvider = CType(Framework.Reflection.CreateObject("data", "YourCompany.Modules.StudentInformation", ""), DataProvider)
to...

objProvider = CType(Framework.Reflection.CreateObject("data", "Company.Modules.StudentInformation", ""), DataProvider)

Where Company.Modules.StudentInformation is the name of the real namespace in my project.

btw for others reading this, the word Company would be replaced by the name of your real company. So if your name space was McDonalds.Modules.StudentInformation that is what you'd put in that line...

objProvider = CType(Framework.Reflection.CreateObject("data", "McDonalds.Modules.StudentInformation", ""), DataProvider)

Then the DNN framework will see your custom data provider and your database methods/calls will work.