Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

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...SQL and SQL Ser...SQL and SQL Ser...Is the DNN PetaPoco DAL limited to accessing SPs in default “dbo” schema?Is the DNN PetaPoco DAL limited to accessing SPs in default “dbo” schema?
Previous
 
Next
New Post
10/23/2015 3:37 PM
Accepted Answer 
yes (as far as I know)

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
10/23/2015 4:08 PM
 

Wow! That's stunning, schemas have been around for over a decade. For the DAL to always assume the schema is the same... no words.

So... what's the recommend way(s) to workaround this limitation when the SPs that must be called are not in the default DNN schema (typically "dbo")?

 
New Post
10/23/2015 4:13 PM
 
I am well aware of Schemas being introduced to SQL Server in Version 2005, but the default DNN connection assumes to use default schema only (which is specified in web.config). It is a constraint, but not a significant one, as long as there is only one SQL server user and not each module having a chance to specify its on security context. What is your requirement for using a different schema?

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
10/23/2015 5:15 PM
 

"I am well aware of Schemas being introduced to SQL Server in Version 2005"... I know you are Sebastian, but DNN acts like its not, hence the problem. DNN still after a decade treats schemas like a hindrance instead of a help. Use of schemas for organizational and security purposes is now a standard with many clients including us, subsequently it's very significant in this case as it requires me to implement a workaround to use DNN.  Hence my question about a doing just that. 

Xmod Pro is a great example where we use its modules to call SPs in other schemas all the time. It's my understanding it uses the DAL so there must be a workaround.

So you don't have a recommendation for working around the limitation other than violating our design specifications?


 

 
New Post
10/23/2015 5:34 PM
 
IMO, DNN should focus on default scenarios. Additional schemas are relevant for extensions, who need to access its own data sources, using web services, custom connection strings etc. but for security reasons, the default connection of DNN should be limited to access a single schema within a single database - anything else might even affect security of the overall system. E.g. I am working to move the tooling for my Turbo scripts into a dedicated schema, instead of creating it ant the beginning and removing it at the end of each of my scripts. I will need a dedicated database user however to use these scripts, preventing the usual DNN runtime user to access those scripts with additional permission. This would be an additional step to improve security of the DNN database.

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeDevelopment and...Development and...SQL and SQL Ser...SQL and SQL Ser...Is the DNN PetaPoco DAL limited to accessing SPs in default “dbo” schema?Is the DNN PetaPoco DAL limited to accessing SPs in default “dbo” schema?


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.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out