Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesSQL code with/without {databaseOwner}{objectQualifier}SQL code with/without {databaseOwner}{objectQualifier}
Previous
 
Next
New Post
11/20/2017 2:06 PM
 

We are developing an APP very strong on DB needs, and we were wondering what benefits our Modules of using the {databaseOwner}{objectQualifier} system proposed by DNN in oposite of using our own definition

Part of the solution is a migration from a previous system where "each module" has its own schema, facilitating maintenance and modularity between projects/modules.

SQL lanscape will be more clear as [ownSchemas].[whatever...] than dbo.dnn_moduleName_whatever ...



 

 
New Post
11/21/2017 1:01 AM
 
Pedro, please be aware that not all hosting companies will support SQL users defining their own schema.
Besides, when hardening DNN security, the SQL Server account used by DNN, should not get access to other schemas by default.
Therefore you should stick to the {databaseOwner}{objectQualifier} system.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
11/21/2017 4:58 PM
 

Hi Sebastian, thanks for response

About the first, we are running on own servers (azure) and no plan to migrate to an external hosting company

About the second, DNN use an account with all privileges, and by default, no other objects than those in dbo exist in an DNN installation (times where a single db stores more than a project has already pass)

I uknow if there are plans to "harden DNN security", by using different DB users for installation, module deployment and normal run. Otherwise, the inconveniente of adding schema permission to the single user used by DNN do not seems like a big inconvenient.

Do not misunderstand me, I like the {databaseOwner}{objectQualifier} system, but this will made for us a lot of code rewriting in porting the existing solution and documentation.

 

 

 
New Post
11/21/2017 5:17 PM
Accepted Answer 
I think Sebastian's comments are important in modules built for sale, or other distribution, to other DNN users.

If you are creating an in-house application then there is no technical need to follow the owner/qualifier system. Of course you would need to be aware that you are moving outside the 'standard' approach and it is possible that you may lose out in some way; either now or in the future.

Best wishes,
- Richard
Agile Development Consultant, Practitioner, and Trainer
www.dynamisys.co.uk
 
New Post
11/22/2017 10:52 AM
 
I agree with Richard: if you don't plan to distribute your modules, you may omit support for databaseOwner and objectQualifier tokens.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesSQL code with/without {databaseOwner}{objectQualifier}SQL code with/without {databaseOwner}{objectQualifier}


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  


Copyright 2018 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out