I'm new to DNN and have started with the new templates written by Chris Hammond for developing DNN modules. I want to separate the tables in the database and have the DNN tables start with the prefix dnn_ and my own tables without this prefix. I can't figure out on how to set this up? Does anyone know?
Thanks, Michael
Michael, If you want to use my templates without the DNN_ in front of your tables, simply remove the references (in the project) to the word objectQualifier.
You'll likely remove them in the SQLDATAPROVIDER.CS file, and in the SQL scripts themselves.
If you're using DAL2 however, it might be more involved.
Related
I have two Django projects that need to use the same postgres database.
I created the database in one of the projects -- no problems;
I just created the second project. It will need access to tables in the database. It will also need some additional tables that only it will access.
Two questions:
In the second project, I am getting the 'unapplied migrations' message from the main app. How do I safely get rid of this? I don't want the second project changing the parts of the database that were created by the first app. However, I don't want necessary Django setup to not be done (is there any)?
Suppose I want to create a table used only by the second project. Should I do it in the second project and migrate it? Or should I do it in the first project to prevent the second project 'messing' with the database?
Many thanks.
I am attempting to gain some knowledge and use cases on SSDT Database development and deployments and strugling with some deployment issues.
Specifically when using nested views. For some unknown reason when attempting to deploy / publish the files in the project to a local / live db it seems to mess up the references in the views.
In this project i have the following views (example):
View1
View2
View3
View1 references View2 and View3 is referencing View1.
Building the project works fine. hoewever when i try to publish the database either by generating a dacpac by snapshot and publish it to the database or let Visual Studio generate an update script after (or not) comparing schemas i end up with an update script which tries to create the views in what seems to be the logical order in which they are stored in the project.
In this case View1 -> View2 -> View3. This means the publish fails because of reference issues. It can't create a view if the referenced view does not exist.
I have tried several options by adding the dacpac as reference in the project in various ways (same database, Same Server different Database w/ w/o database parameter) but in many cases i end up with a sql71561 / SQL71508 error which was another PITA to solve.
Online i can't find any good sources which explains how to work around this issue or which explains how this works properly.
Hopefully i can get some help here. If you need extra input from my side or want me to try something let me know.
Issue has been resolved by new insights. When trying to build the demo code to share with SO community i accidentally found the solution because i needed to clean up sensitive data(model) parts. Please let me elaborate on what was the issue.
The solution can be divided into two solutions:
Configuration of Database Project / Solution
the way references work
I'll share some insights on the both matters.
Configuration of Database Project / Solution
The Visual Studio solution contained a single project in which all views were placed. The actual tables and other database items were separated in different Solutions / Project.
Solution1
Project1
View1
View2
View3
Solution2
Project1
Tables
Security
Schemas
Etc...
The views itself contained three-part identifiers [Database].[Schema].[Table/View]. This was both on the items inside the project (views) and on the items outside the project (tables etc.).
By just using that one separate Project with just the views led to missing references. It was not able to find the other views nor the tables (further see references).
One solution to this issue was making sure both the views and the tables refenced are in the same Solution / Project. Even with using three-part identifiers Visual Studio ignores these because of the existence of all items in the same project / solution. It will detect the dependencies this way.
the way references work
The other way to solve it was using references the right way in visual studio. which is the second possible solution.
Considering the earlier example where the views were in a different solution as the other elements led to missing references. However adding a dacpac as a database reference with the setting Same Database led to conflicting references and SQL71508 element already exists in the model. This is true because it exists in the references dacpac and we try to create a new view with the same name referencing itself in the dacpac. This is because it sees the three-part reference as a variable for the dacpac.
When using the dacpac setting for same Server, Different Database it resolves the mixed up references because it sees the three-part identifiers as an external reference and thinks that you creating a local copy of a view which is looking at the external dacpac. in other words it will not detect the nested view because it thinks you referencing a separate database not inside the project.
When building the project this will not lead to errors and deployment will work. however since it thinks you are referencing an external data source (in the form of a dacpac) it does not see the reference to the other local views.
The solution to this (atleast this worked for us) is to use two-part identifiers in our views when we need a local reference to the other views. This way it will look at other files inside the project instead of the referenced dacpac.
Since it will detect the reference to the other local views it will build correctly and detect the dependancies in the views inside the local project. It will then create a good build order for all views.
I guess you could also assign a different Variable name to the referenced Dacpac, use three-part-identifiers all the way but change the ones in the external dacpac to use the newly assigned variable name. We have not tested this (but i will when i get back home tonight).
So in all this was a good learning experience in how Database references work inside Database projects when using partial projects or when you have split up the database into several projects / solutions. Now to understand this Pandora's black box and convert them into a future-proof solution :)
I've inherited the maintenance of a DotNetNuke (v6.2.0.1610) site, and one of the things I'd like to do is to tidy up the database tables being used.
It looks like there might have been two installations of DNN into the same database (I'm guessing, I don't know its history and cannot find out), I'm making this assumption because there are two sets of DotNetNuke tables.
For example, we have:
dbo.Portals, dbo.PortalSettings, dbo.Profile, dbo.Roles, etc.
However, then we also have the same set, prefixed with dnn_ -
dbo.dnn_Portals, dbo.dnn_PortalSettings, dbo.dnn_Profile, dbo.dnn_Roles, etc.
I spent a good while tearing my hair out when I could not get our portal to load, when I discovered it is because I was editing the dbo.PortalAlias table and I needed to be editing the dbo.dnn_PortalAlias table instead.
I wanted to avoid this future maintenance headache, so I backed up the database, and set about deleting all the tables without the dnn_ prefix (web.config specifies objectQualifier="dnn_"). I diligently ensured there was a matching dnn_ table before deleting any.
At first it seemed fine - the portal loaded and all the content was there, I thought I was on to a winner. However when I logged in and accessed the site admin section, that's when I started to get lots of error messages. So I figured I'd deleted too much, I restored the backup, and all is well - portal working again.
However, I really would like to get rid of the unnecessary tables, because no doubt at some point in the future I'll start doing some work on the database, forget about the dnn_ prefix and waste a bunch of time wondering why something isn't working.
So, as a bit of a DotNetNuke newbie, I'm after some help - how can I know what tables are in use, what aren't, and how can I set about tidying up the SQL Server tables? Thanks.
I suggest you to delete only the tables which have an equivalent with the "dnn_" prefix.
The DNN database should contain at least the "aspnet_" prefixed tables which are used for the authentication on the portals.
Then, you could have some extensions which could use tables without the "dnn_" prefix. It depends on the sql scripts that those extensions have used during their installation. I hope that those extensions don't run queries on the dnn tables without the "dnn_" prefix. Otherwise it could explain the errors you've encountered.
You could use the SQL Server Profiler to check it.
It turns out there was a view, dnn_Lists which was still referencing dbo.Lists without the dnn_ prefix.
I fixed this view and it's fine now.
(PS: Turns out that it's useful to set IsSuperUser = 1 in the users table for who you're logged in as, because then you get the full exception details and can fix it.)
Thanks
It would make sense to delete all tables WITHOUT "dnn_", but you said you got a problem.
If you have time and patience and is adamant about tiding things up, I would delete 1 table at a time and test the admin feature it broke last time until you find the culprit. That is a long shot, but that is how I would approach.
What might be happening here is that you may have a 3rd module installed that ignores the objectQualifier and when you deleted those tables, you then broke that module.
Working with VS2013 and doing my first database project solution. I have three existing databases on the same server. Quotes, Quoting and QuotingUi. Each have a few stored procedures that reference one of the other databases. This is done with database.schema.table (Quotes.dbo.Mytable) syntax and works well in SSMS and all production situations. QuotingUi has a number of views that pull data from Quoting using the same syntax. SPs and EF models have no problem with this.
I have created an empty solution and then added each database to the solution as a project by right clicking on the database in the SQL Object Explorer and Create New Database. Once all three projects are created the solution builds. I do however have warnings on Quotes and Quoting (sps only) that references cannot be resolved to the other database. In QuotingUi I have not only warnings about the sp references but errors (red squigglies) on all the views.
I have tried adding the other projects to each project both as projects (seems it only wants dlls) or databases or both, then rebuild, then close and reopen solution etc. I have set a build dependency for QuoutingUi for the other two projects and a build order that builds them first. No joy.
Have begun Deborah Kurata Pluralsight Course but I do not believe she covers this scenario.
Suggestions welcome.
It sounds like you're still using the existing three part name (e.g. [SameServerDb].[dbo].[Table2]) in your stored procedures and views. You should update it to use the SQLCMD variable name for the reference instead. SQLCMD variables are used so that you could change the referenced database name at deployment time.
This is covered in the help documentation, but here's an example for you. In this case I added a reference to "SameServerDb" as shown below:
Note the "Database Variable" name is $(SameServerDb). Now I just change any reference from [SameServerDb] to [$(SameServerDb)]:
CREATE VIEW [dbo].[View2]
AS SELECT * FROM [$(SameServerDb)].[dbo].[Table2]
For all database projects in your solution, add all their referenced databases: In Solution Explorer window, right click References -> Add database reference, and select the other project. Repeat for all referenced projects. Also, make sure you rebuild all projects.
You can also suppress certain warnings:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/9b698de1-9f6d-4e51-8c73-93c57355e768/treat-specific-warning-as-error?forum=ssdt
I have a pretty old DotNetNuke installation which is broken (in more than one way) and won't let me upgrade. I've set up a new installation and want to move the content. The old portal has a massive amount of data, so moving it manually will take very long.
Is there any way of migrating between portals without manually copying?
I know tools exist to do this between SharePoint portals.
I'm capable of doing SQL and even writing a few lines of code if required.
It depends on where your data is stored. Some modules will implement the "Portable" feature, which means that you can export them with content. However, there's not even a great way to export all of your content at once. You can export a portal template (from Host -> Portals), but if you're upgrading a lot of versions, the new version won't be able to handle the old version.
If your information is in a lot of different modules that don't support the "Portable" feature, you'll need to consider each of those modules separately (probably doing some sort of SQL export specific to each module).
I'm facing this issue now. PokerDIY.com has a massive amount of user-dependant data but runs like a dog. I want to start fresh on DNN 7.1 with a clean install and move the relevant data across and make new pages and content. (I guess by not moving the modules and tabs across it is a bit easier).
Considering the Users will get a new UserID I will have to use email address to map any table with a USerID from the old DB to the new one... this is going to be no small task ;)