Good Evening,

As a result of the module review process, the reviewer pointed out that one of my modules didn't install cleanly when an alternate databaseowner is specified in the web.config.  While none of the 100 or so users have pointed it out, I understand this is a common practice in Shared hosting environments so wish to make well with the dnn compliance gods and fix the issue.

I'm not a complete idiot - just a partial one.  I have dnn at work, dnn on 3 test machines and dnn for breakfast.    I test the modules against three flavors before releasing and include object qualifier as a test that I run.  So, you don't have to be gentle, any replies starting with "Hey, Retard -- " that make this go away -- are greatly welcome.

 So, I set out to setup an additional DNN 4.40 test install based on similar settings to those that I saw in the review, to remedy the issue.  (for use in my module testing)

I do all of the DNN install deals, set web.config, file system properties, yada yada..

I created a DB called dnn.   I created a user called dnn4x.   I give that user, all possible (good) rights to the dnn db (db_owner, datareader, datawriter, secadmin, etc).   I edit the connection string appropriately.  I also set the objectqualifier and databaseowner to "dnn4x" to match what I see in the report.

When I browse to the DNN instance, DNN issues:

Error Installing DotNetNuke

Current Assembly Version: 04.04.00

ERROR: Could not connect to database specified in connectionString for SqlDataProvider

So, I know what you are thinking.  "Hey dummy, you just fat fingered the password or something".  I edit the web.config and change databaseowner to dbo.   Browse and i get installage.

So, I know I'm missing something extremely simple here and I'm curious if anyone can point me in the right direction.   I never really use anything other than dbo on my db objects up until now so I'm sure I'm just missing something.

Thanks in Advance,

Bill Dodd
bill.dodd@gulf-technology.com

Thanks for the reply. 
Yeah, I agree, there seems to be a trick to it.   I know it happens in shared hosting but I'm not sure what magic pills they take to please the installer.

I run some dnn sites, http://www.gulfcommunity.com, www.gulf-technology.com, www.nukeflow.com, www.nuketransfer.com   -- many use object qualifier syntax but I didn't tinker with the dbo on any of them. 

The core team member who tested my module for "DNN Reviewed" status, apparently set both the the dbo and objectqualifier to "dnn4x" on install.  Clearly HIS dnn works - so I know it can, I just need to figure out how he got that far so I can make my module behave according to the commandments of the great and allknowing masters of the dnn universe and marketplace.

I agree with you. conceptually -- I've resisted the object qualifier and dbo replacement variables because I personally hate them and think they have a potential to cause a support nightmare to fledgling module developers such as myself.  But, i guess if it passed the review on the first go around, I wouldn't have to worry about future support issues =)  But, I guess it's pretty common.  PhpNuke, PhpBB and a million other free, open source widgets for web fun use similar features, so I'm sure there's a real good reason that doesn't apply to me.

It's really odd.  The message "cannot connect to db", returned is clearly innacurate. I can login with management studio as that user and do anything I want to the db, so I feel like it isn't permissions related.  As soon as I set "dnn4x" back to "dbo", it's all roses.

DNN Blog | Twitter: @erikvb | LinkedIn: